Асинхронное программирование JavaScript. Сила $. Отложено для приложения HTML5

1. Браузер Асинхронные API
2. Обработка ошибок
3. Положить его вместе с $ .Deferred
4. Случаи применения
5. Заключение

Одним из наиболее важных аспектов построения гладких и отзывчивых приложений HTML5 является синхронизация между всеми различными частями приложения, такими как выборка данных, обработка, анимация и элементы пользовательского интерфейса.

Основное отличие настольного компьютера или собственной среды заключается в том, что браузеры не предоставляют доступ к модели потоков и предоставляют единый поток для всего, что обращается к пользовательскому интерфейсу (например, DOM). Это означает, что вся логика приложения, обращающаяся к элементам пользовательского интерфейса и изменяющая их, всегда находится в одном потоке, поэтому важно сохранять все рабочие блоки приложения как можно меньшими и эффективными, а также использовать любые асинхронные возможности, предлагаемые браузером. возможный.

Браузер Асинхронные API

К счастью, браузеры предоставляют ряд асинхронных API, таких как обычно используемые API-интерфейсы XHR (XMLHttpRequest или 'AJAX'), а также работники IndexedDB, SQLite, HTML5 Web и API-интерфейсы GeoLocation HTML5. Даже некоторые действия, связанные с DOM, отображаются асинхронно, например CSS3-анимация через события transitionEnd.

Браузеры предоставляют асинхронное программирование логике приложения с помощью событий или обратных вызовов. В основанных на событиях асинхронных API разработчики регистрируют обработчик событий для данного объекта (например, HTML-элемент или другие объекты DOM) и затем вызывают действие. Браузер будет выполнять действие, обычно в другом потоке, и при необходимости запускать событие в основном потоке.

Например, код, использующий XHR API, асинхронный API на основе событий, будет выглядеть следующим образом:

Событие CSS3 transitionEnd - еще один пример асинхронного API на основе событий.

Другие API-интерфейсы браузера, такие как SQLite и HTML5 Geolocation, основаны на обратном вызове, что означает, что разработчик передает функцию в качестве аргумента, который будет вызываться базовой реализацией с соответствующим разрешением.

Например, для геолокации HTML5 код выглядит так:

В этом случае мы просто вызываем метод и передаем функцию, которая будет вызываться с запрошенным результатом. Это позволяет браузеру реализовывать эту функцию синхронно или асинхронно и предоставлять единый API разработчику независимо от деталей реализации.

Помимо встроенных в браузер асинхронных API, хорошо спроектированные приложения должны также предоставлять свои низкоуровневые API в асинхронном режиме, особенно когда они выполняют какой-либо ввод-вывод или вычислительную сложную обработку. Например, API для получения данных должны быть асинхронными и НЕ должны выглядеть так:

Этот дизайн API требует, чтобы getData () блокировался, что приведет к остановке пользовательского интерфейса до тех пор, пока данные не будут получены. Если данные являются локальными в контексте JavaScript, это может не вызывать проблем, однако, если данные необходимо получать из сети или даже локально в хранилище SQLite или индекса, это может оказать существенное влияние на взаимодействие с пользователем.

Правильный дизайн состоит в том, чтобы упреждающе сделать все API приложений, для обработки которых может потребоваться некоторое время, с самого начала асинхронным, так как преобразование синхронного кода приложения в асинхронный может быть сложной задачей.

Например, упрощенный API getData () может выглядеть примерно так:

Хорошая вещь в этом подходе состоит в том, что это заставляет код пользовательского интерфейса приложения быть асинхронно-ориентированным с самого начала и позволяет нижележащим API решать, нужно ли им быть асинхронным или нет на более позднем этапе.

Обратите внимание, что не все API приложения должны или должны быть асинхронными. Практическое правило заключается в том, что любой API, который выполняет любой тип ввода-вывода или интенсивную обработку (все, что может занять более 15 мс), должен быть открыт асинхронно с самого начала, даже если первая реализация является синхронной.

Обработка ошибок

Один из недостатков асинхронного программирования заключается в том, что традиционный способ обработки ошибок типа try / catch больше не работает, так как ошибки обычно происходят в другом потоке. Следовательно, вызываемый должен иметь структурированный способ уведомления вызывающего абонента, когда что-то идет не так во время обработки.

В асинхронном API на основе событий это часто выполняется кодом приложения, запрашивающим событие или объект при получении события. Для асинхронных API на основе обратного вызова рекомендуется использовать второй аргумент, который принимает функцию, которая будет вызываться в случае сбоя, с соответствующей информацией об ошибке в качестве аргумента.

Наш вызов getData будет выглядеть так:

Положить его вместе с $ .Deferred

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

Например, если вам нужно подождать два асинхронных API, прежде чем выполнять третий, сложность кода может быстро возрасти.

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

К счастью, существует довольно старая модель, называемая Обещаниями (вроде Будущее в Java) и надежная и современная реализация в ядре jQuery под названием $ .Deferred это обеспечивает простое и мощное решение для асинхронного программирования.

Для простоты шаблон Promises определяет, что асинхронный API возвращает объект Promise, который является своего рода «Обещанием, что результат будет разрешен с соответствующими данными». Чтобы получить разрешение, вызывающая сторона получает объект Promise и вызывает done (successFunc (data)), который сообщит объекту Promise вызывать этот successFunc при разрешении «данных».

Итак, приведенный выше пример вызова getData выглядит так:

Здесь мы сначала получаем объект dataPromise, а затем вызываем метод .done, чтобы зарегистрировать функцию, которую мы хотим вызвать, когда данные будут разрешены. Мы также можем вызвать метод .fail для обработки возможного сбоя. Обратите внимание, что у нас может быть столько вызовов .done или .fail, сколько нам нужно, поскольку базовая реализация Promise (код jQuery) будет обрабатывать регистрацию и обратные вызовы.

С этим шаблоном относительно легко реализовать более продвинутый код синхронизации, и jQuery уже предоставляет наиболее распространенный такой код $ .when ,

Например, вложенный обратный вызов getData / getLocation, приведенный выше, может выглядеть примерно так:

И прелесть всего этого в том, что jQuery.Deferred позволяет разработчикам легко реализовать асинхронную функцию. Например, getData может выглядеть примерно так:

Таким образом, когда вызывается getData (), он сначала создает новый объект jQuery.Deferred (1), а затем возвращает свой Promise (2), чтобы вызывающий мог зарегистрировать свои функции done и fail. Затем, когда вызов XHR возвращается, он либо разрешает отложенный (3.1), либо отклоняет его (3.2). Выполнение deferred.resolve вызовет все функции done (...) и другие функции обещания (например, then и pipe), а вызов deferred.reject вызовет все функции fail ().

Случаи применения

Вот несколько хороших вариантов использования, где Deferred может быть очень полезен:

Доступ к данным. Предоставление API доступа к данным в виде $ .Deferred часто является правильным дизайном. Это очевидно для удаленных данных, поскольку синхронные удаленные вызовы могут полностью испортить взаимодействие с пользователем, но также верно и для локальных данных, поскольку зачастую API более низкого уровня (например, SQLite и IndexedDB) сами по себе являются асинхронными. $ .When и .pipe от Deferred API чрезвычайно эффективны для синхронизации и объединения асинхронных подзапросов.

Анимация пользовательского интерфейса: организация одной или нескольких анимаций с событиями transitionEnd может быть довольно утомительной, особенно когда анимация представляет собой смесь анимации CSS3 и JavaScript (как это часто бывает). Оборачивание функций анимации как Deferred может значительно снизить сложность кода и повысить гибкость. Очень может помочь даже простая универсальная функция-обертка, такая как cssAnimation (className), которая будет возвращать объект Promise, который разрешается на transitionEnd.

Отображение компонентов пользовательского интерфейса: это немного более продвинутое, но в продвинутых инфраструктурах компонентов HTML также следует использовать Deferred. Если не вдаваться в подробности (это будет предметом другого поста), когда приложению необходимо отобразить различные части пользовательского интерфейса, то жизненный цикл этих компонентов, инкапсулированных в Deferred, позволяет лучше контролировать время.

Любой браузерный асинхронный API. В целях нормализации часто рекомендуется переносить вызовы API браузера как отложенные. Это занимает буквально от 4 до 5 строк кода, но значительно упростит любой код приложения. Как показано в приведенном выше псевдокоде getData / getLocation, это позволяет коду приложений иметь одну асинхронную модель для всех типов API (браузеров, спецификаций приложений и составных).

Кэширование: это своего рода побочное преимущество, но может быть очень полезным в некоторых случаях. Поскольку API Promise (например, .done (..) и .fail (..)) можно вызывать до или после выполнения асинхронного вызова, объект Deferred можно использовать как дескриптор кэширования для асинхронного вызова. Например, CacheManager может просто отслеживать Deferred для заданных запросов и возвращать Promise соответствующего Deferred, если он не был аннулирован. Прелесть в том, что вызывающему не нужно знать, был ли вызов уже разрешен или находится в процессе разрешения, его функция обратного вызова будет вызываться точно так же.

Заключение

Хотя концепция $ .Deferred проста, может потребоваться время, чтобы разобраться с ней. Однако, учитывая природу среды браузера, освоение асинхронного программирования на JavaScript является обязательным требованием для любого серьезного разработчика приложений HTML5, и шаблон Promise (и реализация jQuery) являются огромными инструментами, позволяющими сделать асинхронное программирование надежным и мощным.

Похожие

Комментарии