From 841aae260382e2bf5ebb44d765d8c7301d27caab Mon Sep 17 00:00:00 2001 From: Alexey Istomin Date: Sat, 20 Mar 2021 18:37:44 +0300 Subject: Restore "ё" letter in Russian translation (#239) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * docs(ru): restore ё letter * docs(ru): resolve conflicts * refactor(idea): remove ide folder --- files/ru/web/api/service_worker_api/index.html | 12 +++---- .../using_service_workers/index.html | 38 +++++++++++----------- 2 files changed, 25 insertions(+), 25 deletions(-) (limited to 'files/ru/web/api/service_worker_api') diff --git a/files/ru/web/api/service_worker_api/index.html b/files/ru/web/api/service_worker_api/index.html index 7d52ed2334..f7b0bbb1cd 100644 --- a/files/ru/web/api/service_worker_api/index.html +++ b/files/ru/web/api/service_worker_api/index.html @@ -21,7 +21,7 @@ translation_of: Web/API/Service_Worker_API

Концепция и использование Service Worker

-

Service worker — это событийно-управляемый worker, регистрируемый на уровне источника и пути. Он представляет собой JavaScript-файл, который может контролировать веб-страницу/сайт, с которым он ассоциируется, перехватывать и модифицировать запросы навигации и ресурсов, очень гибко кешировать ресурсы, для того чтобы предоставить вам полный контроль над тем, как приложение ведет себя в определенных ситуациях (например, когда сеть не доступна).

+

Service worker — это событийно-управляемый worker, регистрируемый на уровне источника и пути. Он представляет собой JavaScript-файл, который может контролировать веб-страницу/сайт, с которым он ассоциируется, перехватывать и модифицировать запросы навигации и ресурсов, очень гибко кешировать ресурсы, для того чтобы предоставить вам полный контроль над тем, как приложение ведёт себя в определённых ситуациях (например, когда сеть не доступна).

Service worker запускается в контексте воркеров, поэтому он не имеет доступа к DOM и работает в потоке отдельном от основного потока JavaScript, управляющего вашим приложением, а следовательно — не блокирует его. Он призван быть полностью асинхронным; как следствие, синхронные API, такие как XHR и localStorage, в Service Worker'е использовать нельзя.

@@ -55,7 +55,7 @@ translation_of: Web/API/Service_Worker_API

Установка производится в случае если загружаемый файл признается новым — либо отличным от уже установленного service worker (определяется через побайтовое сравнение), либо первым устанавливаемым service воркером для этой страницы/сайта.

-

Если это первый раз, когда service worker оказался доступен, будет проведена установка, а после успешного ее завершения — активация.

+

Если это первый раз, когда service worker оказался доступен, будет проведена установка, а после успешного её завершения — активация.

Если service worker уже существует, новая версия устанавливается в фоновом режиме, но не активируется — worker переходит в состояние в ожидании. Новая версия активируется только тогда, когда больше не останется загруженных страниц, использующих старый service worker. Как только это случится, новый service worker активируется (станет активным воркером). Активация может произойти раньше при использовании {{domxref ("ServiceWorkerGlobalScope.skipWaiting()")}}, а существующие страницы могут быть переведены под контроль активного воркера с помощью {{domxref ("Clients.claim()")}}.

@@ -63,7 +63,7 @@ translation_of: Web/API/Service_Worker_API

Есть также событие activate. Момент, когда это событие наступает, является удачным для очистки старого кеша и всего, что ассоциировалось с предыдущей версией вашего service worker'а.

-

Service worker может отвечать на запросы, используя событие {{domxref("FetchEvent")}}. Вы можете изменять ответ на эти запросы на свое усмотрение используя метод {{domxref("FetchEvent.respondWith") }}.

+

Service worker может отвечать на запросы, используя событие {{domxref("FetchEvent")}}. Вы можете изменять ответ на эти запросы на своё усмотрение используя метод {{domxref("FetchEvent.respondWith") }}.

Заметка: Так как выполнение oninstall/onactivate может занять время, спецификация service worker предоставляет метод waitUntil, который возвращает промис, когда вызывается oninstall или onactivate. Функциональные события не отправляются service worker, пока промис не завершится успешно.

@@ -78,7 +78,7 @@ translation_of: Web/API/Service_Worker_API
-

Давайте начнем этот раздел посмотрев на фрагмент кода ниже — это первый блок кода, который вы увидите в нашем сервис-воркере:

+

Давайте начнём этот раздел посмотрев на фрагмент кода ниже — это первый блок кода, который вы увидите в нашем сервис-воркере:

self.addEventListener('install', (event) => {
   event.waitUntil(
@@ -246,12 +246,12 @@ imgLoad('myLittleVader.jpg').then((response) => {
 
    
  
  1. Здесь мы добавляем обработчик события install к сервис-воркеру (отныне self), и затем вызываем метод {{domxref("ExtendableEvent.waitUntil()") }} объекта события. Такая конструкция гарантирует, что сервис-воркер не будет установлен, пока код, переданный внутри waitUntil(), не завершится с успехом.
    2. 
  
  2. Внутри waitUntil() мы используем метод caches.open(), чтобы создать новый кеш, который назовём v1, это будет первая версия кеша ресурсов. Этот метод возвращает промис для созданного кеша; когда он выполнится, у объекта созданного кеша мы вызовем метод addAll(), который в качестве параметра ожидает получить массив origin-относительных URL всех ресурсов, которые мы хотим хранить в кеше.
    3. 
- 
  3. Если промис будет отклонен, то установка будет завершена неудачно, и воркер ничего не сделает. Это хорошо, потому как вы можете исправить свой код и затем попробовать провести регистрацию в следующий раз.
    4. 
+ 
  4. Если промис будет отклонён, то установка будет завершена неудачно, и воркер ничего не сделает. Это хорошо, потому как вы можете исправить свой код и затем попробовать провести регистрацию в следующий раз.
    5. 
  
  5. После успешной установки сервис-воркер активируется. Этот момент не очень важен при первоначальной установке/активации сервис-воркера, в то же время он имеет большое значение, когда происходит обновление воркера (смотрите раздел {{anch("Обновление вашего сервис-воркера")}}, находящийся ниже).
    6. 
 

 
 

-
На заметку: localStorage работает схожим образом, но в синхронном режиме, поэтому запрещен в сервис-воркерах.

+
На заметку: localStorage работает схожим образом, но в синхронном режиме, поэтому запрещён в сервис-воркерах.

 

 
 

@@ -264,7 +264,7 @@ imgLoad('myLittleVader.jpg').then((response) => {
 
 

 
-
Событие fetch возникает каждый раз, когда запрашиваются любые подконтрольные сервис-воркеру ресурсы, к которым относятся документы из области видимости и другие ресурсы, связанные с этими документами (например, если в index.html происходит кросс-доменный запрос для загрузки изображения, то он тоже попадет в сервис-воркер).

+
Событие fetch возникает каждый раз, когда запрашиваются любые подконтрольные сервис-воркеру ресурсы, к которым относятся документы из области видимости и другие ресурсы, связанные с этими документами (например, если в index.html происходит кросс-доменный запрос для загрузки изображения, то он тоже попадёт в сервис-воркер).

 
 
Вы можете подключить к сервис-воркеру обработчик события fetch и внутри него на объекте события вызвать метод respondWith(), чтобы заменить ответы и показать собственную "магию".

 
@@ -322,7 +322,7 @@ event.request.body

Восстановление неудачных запросов

-

Итак, caches.match(event.request) отработает как нужно только в том случае, если в кеше сервис-воркера будет найдено соответствие запросу. Но что произойдет, если такого соответствия не будет найдено? Если мы не предоставим никакого механизма обработки такой ситуации, то промис выполнится со значением undefined и мы не получим никакого значения.

+

Итак, caches.match(event.request) отработает как нужно только в том случае, если в кеше сервис-воркера будет найдено соответствие запросу. Но что произойдёт, если такого соответствия не будет найдено? Если мы не предоставим никакого механизма обработки такой ситуации, то промис выполнится со значением undefined и мы не получим никакого значения.

К счастью, сервис-воркеры имеют структуру основанную на промисах, что делает тривиальной такую обработку и предоставляет большое количество способов успешно обработать запрос:

@@ -334,9 +334,9 @@ event.request.body ); }); -

Если промис будет отклонен, функция catch() вернет обычный сетевой запрос к внешнему ресурсу. Это значит, что, если сеть доступна, то ресурс просто загрузится с сервера.

+

Если промис будет отклонён, функция catch() вернёт обычный сетевой запрос к внешнему ресурсу. Это значит, что, если сеть доступна, то ресурс просто загрузится с сервера.

-

Если же мы были достаточно умны, то мы не стали бы просто возвращать сетевой запрос, а сохранили бы его результат в кеше, чтобы иметь возможность получить его в offline-режиме. В случае с нашим демо-приложением "Star Wars gallery", это означает, что, если в галерею будет добавлено еще одно изображение, то оно будет получено и сохранено в кеше:

+

Если же мы были достаточно умны, то мы не стали бы просто возвращать сетевой запрос, а сохранили бы его результат в кеше, чтобы иметь возможность получить его в offline-режиме. В случае с нашим демо-приложением "Star Wars gallery", это означает, что, если в галерею будет добавлено ещё одно изображение, то оно будет получено и сохранено в кеше:

self.addEventListener('fetch', (event) => {
   event.respondWith(
@@ -351,11 +351,11 @@ event.request.body
); }); -

Здесь мы возвращаем обычный сетевой запрос, который возвращен вызовом fetch(event.request); этот запрос также является промисом. Когда промис разрешится, мы получим кеш вызвав caches.open('v1'); этот метод также возвращает промис. Когда разрешится уже второй промис, будет использован вызов cache.put(), чтобы поместить ресурс в кеш. Ресурс получен через event.request, а ответ — через клонирование response.clone(). Клон помещается в кеш, а оригинальный ответ передается браузеру, который передает его странице, которая запросила ресурс.

+

Здесь мы возвращаем обычный сетевой запрос, который возвращён вызовом fetch(event.request); этот запрос также является промисом. Когда промис разрешится, мы получим кеш вызвав caches.open('v1'); этот метод также возвращает промис. Когда разрешится уже второй промис, будет использован вызов cache.put(), чтобы поместить ресурс в кеш. Ресурс получен через event.request, а ответ — через клонирование response.clone(). Клон помещается в кеш, а оригинальный ответ передаётся браузеру, который передаёт его странице, которая запросила ресурс.

-

Почему? Потому что потоки запроса и ответа могут быть прочитаны только единожды. Чтобы ответ был получен браузером и сохранен в кеше, нам нужно клонировать его. Так оригинальный объект отправится браузеру, а клон будет закеширован. Оба они будут прочитаны единожды.

+

Почему? Потому что потоки запроса и ответа могут быть прочитаны только единожды. Чтобы ответ был получен браузером и сохранён в кеше, нам нужно клонировать его. Так оригинальный объект отправится браузеру, а клон будет закеширован. Оба они будут прочитаны единожды.

-

У нас все ещё остается единственная проблема - если на какой-либо запрос в кеше не будет найдено соответствие, и в этот момент сеть не доступна, то наш запрос завершится неудачно. Давайте реализуем запасной вариант по умолчанию, при котором пользователь, в описанном случае, будет получать хоть что-нибудь:

+

У нас все ещё остаётся единственная проблема - если на какой-либо запрос в кеше не будет найдено соответствие, и в этот момент сеть не доступна, то наш запрос завершится неудачно. Давайте реализуем запасной вариант по умолчанию, при котором пользователь, в описанном случае, будет получать хоть что-нибудь:

self.addEventListener('fetch', (event) => {
   event.respondWith(
@@ -406,7 +406,7 @@ event.request.body

Удаление старого кеша

-

Вы можете обрабатывать событие activate. Оно обычно используется в случае, если нужно выполнить такие действия, которые бы нарушили работу воркеров предыдущей версии, если они все еще работают со старым кешем. Также это событие полезно использовать для того, чтобы удалить ненужные данные, чтобы освободить место, занимаемое на диске, потому что каждый браузер имеет жесткие ограничения на размер хранилища кеша, которое доступно для использования сервис-воркерами.

+

Вы можете обрабатывать событие activate. Оно обычно используется в случае, если нужно выполнить такие действия, которые бы нарушили работу воркеров предыдущей версии, если они все ещё работают со старым кешем. Также это событие полезно использовать для того, чтобы удалить ненужные данные, чтобы освободить место, занимаемое на диске, потому что каждый браузер имеет жёсткие ограничения на размер хранилища кеша, которое доступно для использования сервис-воркерами.

Promise, переданный в waitUntil(), заблокирует другие события до своего завершения, поэтому можно быть уверенным, что процесс очистки закончится раньше, чем выполнится первое событие fetch на основе нового кеша.

-- cgit v1.2.3-54-g00ecf