Skip to content

Commit 2a0e215

Browse files
committed
es6
1 parent 4520279 commit 2a0e215

3 files changed

Lines changed: 193 additions & 0 deletions

File tree

4-ajax/14-fetch/article.md

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
2+
# Метод fetch: замена XMLHttpRequest
3+
4+
Метод [fetch](https://fetch.spec.whatwg.org/) -- это `XMLHttpRequest` нового поколения. Он предоставляет улучшенный интерфейс для осуществления запросов к серверу: как по части возможностей и контроля над происходящим, так и по синтаксису, так как построен на [промисах](/promise).
5+
6+
Поддержка в браузерах пока не очень распространена, но есть [полифилл](https://github.com/github/fetch) и не один.
7+
8+
## Синтаксис
9+
10+
Синтаксис метода `fetch`:
11+
```js
12+
let promise = fetch(url[, options]);
13+
```
14+
15+
<ul>
16+
<li>`url` -- URL, на который сделать запрос,</li>
17+
<li>`options` -- необязательный объект с настройками запроса.</li>
18+
</ul>
19+
20+
Свойства `options`:
21+
<ul>
22+
<li>`method` -- метод запроса,</li>
23+
<li>`headers` -- заголовки запроса (объект),</li>
24+
<li>`body` -- тело запроса: `FormData`, `Blob`, строка и т.п.</li>
25+
<li>`mode` -- одно из: "same-origin", "no-cors", "cors", указывает режим в каком режиме кросс-доменности предполагается делать запрос.</li>
26+
<li>`credentials` -- одно из: "omit", "same-origin", "include", указывает, пересылать ли куки и заголовки авторизации вместе с запросом.</li>
27+
<li>`cache` -- одно из "default", "no-store", "reload", "no-cache", "force-cache", "only-if-cached", указывает, как кешировать запрос.</li>
28+
<li>`redirect` -- можно поставить "follow" для обычного поведения при коде 30x (следовать редиректу) или "error" для интерпретации редиректа как ошибки.</li>
29+
</ul>
30+
31+
Как видно, всевозможных настроек здесь больше, чем в `XMLHttpRequest`. Вместе с тем, надо понимать, что если мы используем полифилл, то ничего более гибкого, чем оригинальный `XMLHttpRequest` мы из этого не получим.
32+
33+
Разве что, `fetch`, возможно, будет удобнее пользоваться.
34+
35+
## Использование
36+
37+
При вызове `fetch` возвращает промис, который, когда получен ответ, выполняет коллбэки с объектом [Response](https://fetch.spec.whatwg.org/#response) или с ошибкой, если запрос не удался.
38+
39+
Пример использования:
40+
41+
```js
42+
//+ run
43+
'use strict';
44+
45+
fetch('/article/fetch/user.json')
46+
.then(function(response) {
47+
alert(response.headers.get('Content-Type')); // application/json; charset=utf-8
48+
alert(response.status); // 200
49+
50+
return response.json();
51+
})
52+
.then(function(user) {
53+
alert(user.name); // iliakan
54+
})
55+
.catch( alert );
56+
```
57+
58+
Объект `response` кроме доступа к заголовкам `headers`, статусу `status` и некоторым другим полям ответа, даёт возможность прочитать его тело, в желаемом формате.
59+
60+
Варианты описаны в спецификации [Body](https://fetch.spec.whatwg.org/#body), они включают в себя:
61+
62+
<ul>
63+
<li>`response.arrayBuffer()`</li>
64+
<li>`response.blob()`</li>
65+
<li>`response.formData()`</li>
66+
<li>`response.json()`</li>
67+
<li>`response.text()`</li>
68+
</ul>
69+
70+
Соответствующий вызов возвращает промис, который, когда ответ будет получен, вызовет коллбэк с результатом.
71+
72+
В примере выше мы можем в первом `.then` проанализировать ответ и, если он нас устроит -- вернуть промис с нужным форматом. Следующий `.then` уже будет содержать полный ответ сервера.
73+
74+
Больше примеров вы можете найти в описании [полифилла для fetch](https://github.com/github/fetch).
75+
76+
## Итого
77+
78+
Метод `fetch` -- уже сейчас удобная альтернатива `XMLHttpRequest` для тех, кто не хочет ждать и любит промисы.
79+
80+
Детальное описание этого метода есть в стандарте [Fetch](https://fetch.spec.whatwg.org/), а простейшие примеры запросов -- в описании к [полифиллу](https://github.com/github/fetch).

4-ajax/14-fetch/user.js

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
{
2+
"name": "iliakan",
3+
"isAdmin": true
4+
}

4-ajax/15-ajax-summary/article.md

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
# Таблица транспортов и их возможностей
2+
3+
Здесь мы подведём итог раздела, сравним транспорты и их возможности.
4+
[cut]
5+
6+
## Способы опроса сервера
7+
8+
Основные способы опроса сервера:
9+
<ol>
10+
<li>**Частые опросы** -- регулярно к серверу отправляется запрос за данными. Сервер тут же отвечает на него, возвращая данные, если они есть. Если нет -- получается, что запрос был зря.
11+
12+
Этот способ очень лёгок в реализации, но приводит к большому количеству лишних запросов, поэтому мы его далее не рассматриваем.
13+
</li>
14+
<li>**Длинные опросы** -- к серверу отправляется запрос за данными. Сервер не отвечает на него, пока данные не появятся. Когда данные появились -- ответ с ними отправляется в браузер, и тот тут же делает новый запрос.
15+
16+
Способ хорош, пока сообщений не слишком много. В идеальном случае соединение почти всё время висит открытым, лишь иногда сервер отвечает на него, доставляя данные в браузер.
17+
18+
Также удобен в реализации, но даёт большое количество висящий соединений на сервере. Не все сервера хорошо поддерживают это. Например, `Apache` будет есть очень много памяти.
19+
</li>
20+
<li>**Потоковое соединение** -- открыто соединение к серверу, и через него непрерывно поступают данные.</li>
21+
</ol>
22+
23+
## Таблица транспортов
24+
Основные характеристики всех транспортов, которые мы обсуждали в деталях, собраны в этой таблице.
25+
26+
Они были детально рассмотрены в предыдущих главах раздела.
27+
28+
<table>
29+
<thead>
30+
<tr>
31+
<th></th>
32+
<th>`XMLHttpRequest`</th>
33+
<th>`IFRAME`</th>
34+
<th>`SCRIPT`</th>
35+
<th>`EventSource`</th>
36+
<th>`WebSocket`</th>
37+
</tr>
38+
</thead>
39+
<tbody>
40+
<tr>
41+
<th>Кросс-доменность</th>
42+
<td>да, кроме IE9-<a class="link-ref" href="#x1">x1</a></td>
43+
<td>да<a class="link-ref" href="#i1">i1</a></td>
44+
<td>да</td>
45+
<td>да</td>
46+
<td>да</td>
47+
</tr>
48+
<tr>
49+
<th>Методы</th>
50+
<td>Любые</td>
51+
<td>GET / POST</td>
52+
<td>GET</td>
53+
<td>GET</td>
54+
<td>Свой протокол</td>
55+
</tr>
56+
<tr>
57+
<th>COMET</th>
58+
<td>Длинные опросы<a class="link-ref" href="#x2">x2</a></td>
59+
<td>Непрерывное соединение</td>
60+
<td>Длинные опросы</td>
61+
<td>Непрерывное соединение</td>
62+
<td>Непрерывное соединение в обе стороны</td>
63+
</tr>
64+
<tr>
65+
<th>Поддержка</th>
66+
<td>Все браузеры, ограничения в IE9-<a class="link-ref" href="#x3">x3</a></td>
67+
<td>Все браузеры</td>
68+
<td>Все браузеры</td>
69+
<td>Кроме IE</td>
70+
<td>IE 10, FF11, Chrome 16, Safari 6, Opera 12.5<a class="link-ref" href="#w1">w1</a></td>
71+
</tr>
72+
</tbody>
73+
</table>
74+
75+
Пояснения:
76+
77+
<dl>
78+
<dt>`XMLHttpRequest`</dt>
79+
<dd>
80+
<ol>
81+
<li id="x1">В IE8-9 поддерживаются кросс-доменные GET/POST запросы с ограничениями через `XDomainRequest`.</li>
82+
<li id="x2">Можно говорить об ограниченной поддержке непрерывного соединения через `onprogress`, но это событие вызывается не чаще чем в `50ms` и не гарантирует получение полного пакета данных. Например, сервер может записать "Привет!", а событие вызовется один раз, когда браузер получил "При". Поэтому наладить обмен пакетами сообщений с его помощью затруднительно.
83+
</li>
84+
<li id="x3">Многие возможности современного стандарта включены в IE лишь с версии 10.</li>
85+
</ol>
86+
</dd>
87+
<dt>`IFRAME`</dt>
88+
<dd>
89+
<ol>
90+
<li id="i1">Во всех современных браузерах и IE8 кросс-доменность обеспечивает `postMessage`. В более старых браузерах возможны решения через `window.name` и хэш.</li>
91+
</ol>
92+
</dd>
93+
<dt>`WebSocket`</dt>
94+
<dd>
95+
<ol>
96+
<li id="w1">Имеется в виду поддержка окончательной редакции протокола [RFC 6455](http://tools.ietf.org/html/rfc6455), описанной в разделе [](/websockets). Более старые браузеры могут поддерживать черновики протокола. IE9- не поддерживает `WebSocket`.</li>
97+
</ol>
98+
</dd>
99+
</dl>
100+
101+
Существует также нестандартный транспорт, не рассмотренный здесь:
102+
<ul>
103+
<li>XMLHttpRequest с флагом `multipart`, только для Firefox.
104+
105+
При указании свойства `xhr.multipart = true` и специального multipart-формата ответа сервера, Firefox инициирует `onload` при получении очередной части ответа. Ответ может состоять из любого количества частей, досылаемых по инициативе сервера. Мы не рассматривали его, так как Firefox поддерживает другие, более кросс-браузерные и стандартные транспорты.
106+
</li>
107+
</ul>
108+
109+
В современных браузерах поддерживается новый метод [fetch](/fetch), в качестве замены XMLHttpRequest ([полифилл](https://github.com/github/fetch)).

0 commit comments

Comments
 (0)