Table of Content
Реалізація API покладається на браузери. Браузери реалізують цю функціональність за допомогою інтерфейсів, які забезпечуються певними об’єктами з об’єктною моделлю документа. Ці об’єкти входять до складу глобального об’єкта window. Що створює загальний контекст клієнтських програмних компонентів DOM. Вказані об’єкти є властивостями об’єкта window та реалізують інтерфейси через відповідні властивості, методи та події. Серед найбільш важливих АРІ зазначимо такі:
  1. History API – для управління історією браузера.
  2. Application Cache API – управління механізмами кешування для забезпечення автономної роботи
  3. Web Workers API – для виконання фонових задач в окремих потоках.
  4. API, що реалізують клієнтські сховища данних.
    1. Local Storage API -механізм, що реалізує локально сховище даних у вигляді пар (ключ => значення)
    2. IndexedDB – що реалізує зберігання локально зберігати дані у вигляді структури JavaScript об’єктів.
  5. Api для обміну даними між сервером та клієнтом.
    1. SSE (Server Side Events) – API, що забезпечує обмін даними за ініціативою сервера.
    2. WEbSockets – API, що забезпечує механізм повнодуплексного обміну даними між клієнтом та сервером.

History API
Реалізує механізми управління історією браузера через відповідний об’єкт history. 
  1. Переміщення по історії. Здійснюється за допомогою наступних методів:
    1. back() – переміщення на один крок назад
    2. forward() – переміщення на один крок вперед
    3. go(n) – переміщення на кілька кроків, n – це кількість кроків може бути додатнім або від’ємним, який визначає напрямок руху вперед або назад.
  2. Додавання записів до історії. Здійснюється за допомогою наступних методів:
    1. pushState(stateObject, title, url) ця функція приймає 3 параметри
      1. stateObject – об’єкт який асоційований записом історії, що додається. В якості такого об’єкта підлягає все, що підлягає серіалізації. Наприклад (JS об’єкт).
      2. title – Назва для записа, асоційований записом
      3. url асоційований з цим записом.
  3. Заміна запису історії, здійснюється за допомогою метода
    1. replaceState, який відрізняється від pushState тим, що новий запис не створюється і додається, а замінює останній запис в історії.
  4. Отримання інформації про стан історії. Це реалізується за допомогою відповідної властивості state.
  5. Подія зміни стану. Подія має назву popstate, генерується кожного разу при переході на нову сторінку. При цьому об’єкт event, що описує події (цей об’єкт передається обробнику) має властивість state, що містить копію об’єкту стану.
Application Cache API
Application Cache API – реалізує набір функцій автономну роботу (без підключення до інтернету) з ресурсами, що були раніше завантаженні. Таким чином реалізує керований механізм кешування альтернативний стандартному механізму кешування браузера. Механізм кешування Application Cache має такі основні відміності від стандартного механізму кешування:
  1. Ресурси, що зберігаються в стандартному кеші браузера можуть бути вилучені без участі користувача або сервера за таких умов:
    1. Заповнення кешу
    2. При завершенні терміну зберігання, що визначається заголовками. У випадку Application Cache ресурси можуть бути вилучені за участі клієнта або сервера.
    3. В стандартний кеш завантажуються лише рсурси, що асоційовані з даним документом. У випадку з Application Cache можна встановлювати правила за якими завантажуватиметься будь-який ресурс.
Управління кеш може здійснюватись 2 способами:
  1. Програмно за допомогою відповідного об’єкта applicationCache
  2. За допомогою спеціального файлу – маніфесту в якому задаються певні правила.
Файл-маніфеста
Файл маніфеста можна асоціювати за допомогою спеціально атрибута ‘manifest’ тега html. В якості значення атрибута виступає ім’я відповідно файлу. Загалом це ім’я може бути вільним. Файл маніфеста складається з:
  1. Початкового рядка: CACHE MANIFEST, що є обов’язкового та регламентує, що цей файл є файлом маніфесту.
  2. 3 розділів
    1. CACHE
    2. NETWORK
    3. FALLBACK
Кожен розділ включає:
  1. Заголовок у вигляді відповідної назви з двокрапкою вкінці (приклад, CACHE:)
  2. Певні url або правила.
Розділ Cache 
Цей розділ є розділом за замовчуванням, це означає що якщо файл маніфесту не містить жодного розділу то його вміст вважається вмістом розділу CACHE. Розділ Cache містить url тих ресурсів, що мають бути завантаженні разом з даною сторінкою. При заданні цих url не можна використовувати символи підстановки.
Розділ Network 
Вказуються url тих ресурсів, що мають бути обов’язково завантажені з інтернету. Якщо ці ресурси відсутні в кеші то в розділі оффлайн вважаються недоступними. В url цього розділу можна використовувати символи підстановки. Часто вмістом цього розділу використовується *, що означає “все”.
Розділ Fallback
В цьому розділі визначаються правила поведінки браузера у випадку звертання в режимі оффлайн до ресурсів, що відсутні в кеші. Вказані правила задаються у формі:
ресурс_що_запитується(пробіл)ресурс_що_відображається
Документ в якому визначено атрибут маніфест є таким, що автоматично кешується браузером (не має необхідності вказувати url цього документа в розділі Cache)
Програмний інтерфейс для Application Cache. API Application Cache представлений об’єктом applicationCache, що реалізує механізм управління кешуванням. Цей об’єкт характеризується такими методами, властивостями та подіями:
  1. Властивість state – визначає стан кешу.
  2. Метод update – ініціює процес отримання оновлених ресурсів з кешу.
  3. Метод swapCache– забезпечує переключення на використання оновленого кешу.
  4. Події
    1. cached
    2. checking
    3. downloading
    4. progress
    5. noupdate
    6. updateready
Механізм роботи кеш.
В процесі використання кешу реалізуються наступні дії:
  1. Початкове завантаженя документу з визначеним атрибутом ‘Manifest’
    1. Здійснюється на отримання файлу маніфесту. (checking)
    2. Здійснюється завантаження ресурсів, згідно з правилами вказаними у файлі маніфесту (downloading + progress, для кожного окремого ресурсу)
    3. Як результат формується перше сховище даних кеш (cached)
  2. Повторне звернення до документа
    1. Оскільки документ обов’язково вже знаходиться в кеші то він береться з нього, звернення до сервера при цьому не відбувається
    2. Об’єкт управлінням кешом ініціює перевірку оновлення файлу маніфесту, здійснюючи запит. (checking)
    3. Сервер надсилає відповідь на запит пункту 2.2
      1. файл маніфесту не змінювався – процес завершується (noupdate)
      2. файл маніфесту змінився:
        1. ініціюється фонове завантаження ресурсів, це не супроводжується негайним оновленням сторінки, оновлений кеш буде використано при наступному зверненні до документа. (downloading + progress)
        2. завершення завантаження (updateready)
Технологія Webworker
Це технологія, що забезпечує виконання JS коду в окремому потоці. Ця технологія в основному використовується для фонової обробки. Головною метою є розвантажити основний потік, який здійснює взаємодію з користувачем. Webworker створюються за допомогою спеціальних конструкторів, що отримують у якості аргументу url файл з скриптом, в якому описаний алгоритм роботи worker. При цьому Workers поділяються на 2 типи:
  1. Виділений – worker який ——
  2. Спільний – такий worker доступний декільком скриптам.
Взаємодія workers з основним потоком.
Взаємодія workers з основним потоком здійснюється за допомогою механізму повідомлень. Повідомлення можуть надсилатись з основного потока воркеру та з воркеру в основний потік, за допомогою функції postMessage, функція приймає в якості аргумента повідомлення, що в загальному випадку може бути —.
Обробка повідомлень здійснюється за допомогою відповідних обробників, що співставляються повідомленням через властивість onmessage. Значенням цієї властивості є функція, що й буде виступати в якості обробника. Аргументом цієї функції є об’єкт події, що має властивість data значенням якої – отримане повідомлення. Отже, з боку основного скрипта, код створення та взаємодії з виділеним “worker”:
  1. Створення: worker = new Worker(“ім’я_файла_скрипта”)
  2. Надсилання повідомлення: worker.postMessage(об’єкт повідомлення)
  3. Реєстрація обробника повідомлення від worker: worker.onmessage = function(e) { код обробника };
  4. Припинення роботи worker:  worker.terminate();
Код воркера
Виділений вокер
Вокер може виконувати, працювати автономно за певним алгоритмом вписаним у відповідному файлі скрипта або виконувати певні дії отримані в повідомлені від основного потоку. В другому випадку обробник повідомлень визначається у такий спосіб: onmessage = function (e) { код обробника }; Крім обробника повідомлень, воркер може містити якийсь інший код. В будь-якому коді, може бути надіслане повідомлення основному потоку викликом функції postMessage (об’єкт повідомлення)
Cпільні вокери – використання спільних вокерів має наступні особливості:
  1. Створюються за допомогою конструктора SharedWorker
  2. Обмін повідомлення з іншими скриптами здійснюється через порт Перед посилкою повідомлень порт потрібно стартувати: shWorker.port.Start(); Прив’язка обробника повідомлення має наступний вигляд: shWorker.port.onmessage = function (e) { код обробника };
Особливості використання вокерів та відповідні обмеження їх функціональності
Відзначимо такі особливості:
  1. Вокери використовують глобальний контекст відмінний від глобального контексту об’єкту window.
  2. Вокер не може напряму працювати з об’єктною моделлю документу. Він може змінити об’єктну модель шляхом надсилання повідомлень в основний поток. Відповідні дії по змінні об’єктної моделі реалізуються в обробнику, тобто в основному скрипті.
  3. Вокери можуть використовувати:
    1. об’єкти:
      1. XMLHttpRequest (для здійснення AJAX запитів)
      2. Data, Math, String, Array
      3. Значну кількість об’єктів, що представляють HTML5 API, наприклад (WebSockets, IndexDB тощо)
    2. Функції setTimeout, setInterval – реалізація періодичних дій вокером.
Last modified: 11.05.2018

Author

Comments

Write a Reply or Comment

Your email address will not be published.