es6
This commit is contained in:
Ilya Kantor
parent
4520279a93
commit
2a0e215368
3 changed files with 193 additions and 0 deletions
80
4-ajax/14-fetch/article.md
Normal file
80
4-ajax/14-fetch/article.md
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
|
||||
# Метод fetch: замена XMLHttpRequest
|
||||
|
||||
Метод [fetch](https://fetch.spec.whatwg.org/) -- это `XMLHttpRequest` нового поколения. Он предоставляет улучшенный интерфейс для осуществления запросов к серверу: как по части возможностей и контроля над происходящим, так и по синтаксису, так как построен на [промисах](/promise).
|
||||
|
||||
Поддержка в браузерах пока не очень распространена, но есть [полифилл](https://github.com/github/fetch) и не один.
|
||||
|
||||
## Синтаксис
|
||||
|
||||
Синтаксис метода `fetch`:
|
||||
```js
|
||||
let promise = fetch(url[, options]);
|
||||
```
|
||||
|
||||
<ul>
|
||||
<li>`url` -- URL, на который сделать запрос,</li>
|
||||
<li>`options` -- необязательный объект с настройками запроса.</li>
|
||||
</ul>
|
||||
|
||||
Свойства `options`:
|
||||
<ul>
|
||||
<li>`method` -- метод запроса,</li>
|
||||
<li>`headers` -- заголовки запроса (объект),</li>
|
||||
<li>`body` -- тело запроса: `FormData`, `Blob`, строка и т.п.</li>
|
||||
<li>`mode` -- одно из: "same-origin", "no-cors", "cors", указывает режим в каком режиме кросс-доменности предполагается делать запрос.</li>
|
||||
<li>`credentials` -- одно из: "omit", "same-origin", "include", указывает, пересылать ли куки и заголовки авторизации вместе с запросом.</li>
|
||||
<li>`cache` -- одно из "default", "no-store", "reload", "no-cache", "force-cache", "only-if-cached", указывает, как кешировать запрос.</li>
|
||||
<li>`redirect` -- можно поставить "follow" для обычного поведения при коде 30x (следовать редиректу) или "error" для интерпретации редиректа как ошибки.</li>
|
||||
</ul>
|
||||
|
||||
Как видно, всевозможных настроек здесь больше, чем в `XMLHttpRequest`. Вместе с тем, надо понимать, что если мы используем полифилл, то ничего более гибкого, чем оригинальный `XMLHttpRequest` мы из этого не получим.
|
||||
|
||||
Разве что, `fetch`, возможно, будет удобнее пользоваться.
|
||||
|
||||
## Использование
|
||||
|
||||
При вызове `fetch` возвращает промис, который, когда получен ответ, выполняет коллбэки с объектом [Response](https://fetch.spec.whatwg.org/#response) или с ошибкой, если запрос не удался.
|
||||
|
||||
Пример использования:
|
||||
|
||||
```js
|
||||
//+ run
|
||||
'use strict';
|
||||
|
||||
fetch('/article/fetch/user.json')
|
||||
.then(function(response) {
|
||||
alert(response.headers.get('Content-Type')); // application/json; charset=utf-8
|
||||
alert(response.status); // 200
|
||||
|
||||
return response.json();
|
||||
})
|
||||
.then(function(user) {
|
||||
alert(user.name); // iliakan
|
||||
})
|
||||
.catch( alert );
|
||||
```
|
||||
|
||||
Объект `response` кроме доступа к заголовкам `headers`, статусу `status` и некоторым другим полям ответа, даёт возможность прочитать его тело, в желаемом формате.
|
||||
|
||||
Варианты описаны в спецификации [Body](https://fetch.spec.whatwg.org/#body), они включают в себя:
|
||||
|
||||
<ul>
|
||||
<li>`response.arrayBuffer()`</li>
|
||||
<li>`response.blob()`</li>
|
||||
<li>`response.formData()`</li>
|
||||
<li>`response.json()`</li>
|
||||
<li>`response.text()`</li>
|
||||
</ul>
|
||||
|
||||
Соответствующий вызов возвращает промис, который, когда ответ будет получен, вызовет коллбэк с результатом.
|
||||
|
||||
В примере выше мы можем в первом `.then` проанализировать ответ и, если он нас устроит -- вернуть промис с нужным форматом. Следующий `.then` уже будет содержать полный ответ сервера.
|
||||
|
||||
Больше примеров вы можете найти в описании [полифилла для fetch](https://github.com/github/fetch).
|
||||
|
||||
## Итого
|
||||
|
||||
Метод `fetch` -- уже сейчас удобная альтернатива `XMLHttpRequest` для тех, кто не хочет ждать и любит промисы.
|
||||
|
||||
Детальное описание этого метода есть в стандарте [Fetch](https://fetch.spec.whatwg.org/), а простейшие примеры запросов -- в описании к [полифиллу](https://github.com/github/fetch).
|
||||
4
4-ajax/14-fetch/user.js
Normal file
4
4-ajax/14-fetch/user.js
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
{
|
||||
"name": "iliakan",
|
||||
"isAdmin": true
|
||||
}
|
||||
109
4-ajax/15-ajax-summary/article.md
Normal file
109
4-ajax/15-ajax-summary/article.md
Normal file
|
|
@ -0,0 +1,109 @@
|
|||
# Таблица транспортов и их возможностей
|
||||
|
||||
Здесь мы подведём итог раздела, сравним транспорты и их возможности.
|
||||
[cut]
|
||||
|
||||
## Способы опроса сервера
|
||||
|
||||
Основные способы опроса сервера:
|
||||
<ol>
|
||||
<li>**Частые опросы** -- регулярно к серверу отправляется запрос за данными. Сервер тут же отвечает на него, возвращая данные, если они есть. Если нет -- получается, что запрос был зря.
|
||||
|
||||
Этот способ очень лёгок в реализации, но приводит к большому количеству лишних запросов, поэтому мы его далее не рассматриваем.
|
||||
</li>
|
||||
<li>**Длинные опросы** -- к серверу отправляется запрос за данными. Сервер не отвечает на него, пока данные не появятся. Когда данные появились -- ответ с ними отправляется в браузер, и тот тут же делает новый запрос.
|
||||
|
||||
Способ хорош, пока сообщений не слишком много. В идеальном случае соединение почти всё время висит открытым, лишь иногда сервер отвечает на него, доставляя данные в браузер.
|
||||
|
||||
Также удобен в реализации, но даёт большое количество висящий соединений на сервере. Не все сервера хорошо поддерживают это. Например, `Apache` будет есть очень много памяти.
|
||||
</li>
|
||||
<li>**Потоковое соединение** -- открыто соединение к серверу, и через него непрерывно поступают данные.</li>
|
||||
</ol>
|
||||
|
||||
## Таблица транспортов
|
||||
Основные характеристики всех транспортов, которые мы обсуждали в деталях, собраны в этой таблице.
|
||||
|
||||
Они были детально рассмотрены в предыдущих главах раздела.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th></th>
|
||||
<th>`XMLHttpRequest`</th>
|
||||
<th>`IFRAME`</th>
|
||||
<th>`SCRIPT`</th>
|
||||
<th>`EventSource`</th>
|
||||
<th>`WebSocket`</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>Кросс-доменность</th>
|
||||
<td>да, кроме IE9-<a class="link-ref" href="#x1">x1</a></td>
|
||||
<td>да<a class="link-ref" href="#i1">i1</a></td>
|
||||
<td>да</td>
|
||||
<td>да</td>
|
||||
<td>да</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Методы</th>
|
||||
<td>Любые</td>
|
||||
<td>GET / POST</td>
|
||||
<td>GET</td>
|
||||
<td>GET</td>
|
||||
<td>Свой протокол</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>COMET</th>
|
||||
<td>Длинные опросы<a class="link-ref" href="#x2">x2</a></td>
|
||||
<td>Непрерывное соединение</td>
|
||||
<td>Длинные опросы</td>
|
||||
<td>Непрерывное соединение</td>
|
||||
<td>Непрерывное соединение в обе стороны</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Поддержка</th>
|
||||
<td>Все браузеры, ограничения в IE9-<a class="link-ref" href="#x3">x3</a></td>
|
||||
<td>Все браузеры</td>
|
||||
<td>Все браузеры</td>
|
||||
<td>Кроме IE</td>
|
||||
<td>IE 10, FF11, Chrome 16, Safari 6, Opera 12.5<a class="link-ref" href="#w1">w1</a></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Пояснения:
|
||||
|
||||
<dl>
|
||||
<dt>`XMLHttpRequest`</dt>
|
||||
<dd>
|
||||
<ol>
|
||||
<li id="x1">В IE8-9 поддерживаются кросс-доменные GET/POST запросы с ограничениями через `XDomainRequest`.</li>
|
||||
<li id="x2">Можно говорить об ограниченной поддержке непрерывного соединения через `onprogress`, но это событие вызывается не чаще чем в `50ms` и не гарантирует получение полного пакета данных. Например, сервер может записать "Привет!", а событие вызовется один раз, когда браузер получил "При". Поэтому наладить обмен пакетами сообщений с его помощью затруднительно.
|
||||
</li>
|
||||
<li id="x3">Многие возможности современного стандарта включены в IE лишь с версии 10.</li>
|
||||
</ol>
|
||||
</dd>
|
||||
<dt>`IFRAME`</dt>
|
||||
<dd>
|
||||
<ol>
|
||||
<li id="i1">Во всех современных браузерах и IE8 кросс-доменность обеспечивает `postMessage`. В более старых браузерах возможны решения через `window.name` и хэш.</li>
|
||||
</ol>
|
||||
</dd>
|
||||
<dt>`WebSocket`</dt>
|
||||
<dd>
|
||||
<ol>
|
||||
<li id="w1">Имеется в виду поддержка окончательной редакции протокола [RFC 6455](http://tools.ietf.org/html/rfc6455), описанной в разделе [](/websockets). Более старые браузеры могут поддерживать черновики протокола. IE9- не поддерживает `WebSocket`.</li>
|
||||
</ol>
|
||||
</dd>
|
||||
</dl>
|
||||
|
||||
Существует также нестандартный транспорт, не рассмотренный здесь:
|
||||
<ul>
|
||||
<li>XMLHttpRequest с флагом `multipart`, только для Firefox.
|
||||
|
||||
При указании свойства `xhr.multipart = true` и специального multipart-формата ответа сервера, Firefox инициирует `onload` при получении очередной части ответа. Ответ может состоять из любого количества частей, досылаемых по инициативе сервера. Мы не рассматривали его, так как Firefox поддерживает другие, более кросс-браузерные и стандартные транспорты.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
В современных браузерах поддерживается новый метод [fetch](/fetch), в качестве замены XMLHttpRequest ([полифилл](https://github.com/github/fetch)).
|
||||
Loading…
Add table
Add a link
Reference in a new issue