Впровадження компонентного підходу до Інтернету огляд веб-компонентів

огляд

Зміст:

  • Впровадження компонентів: стара практика проектування, що стала новою для Інтернету
  • Як розбивати на компоненти
  • Це все не вперше: попередні підходи до впровадження компонентів
  • Сучасні веб-компоненти
  • Веб-компоненти: наступне покоління

Впровадження компонентів: стара практика проектування, що стала новою для Інтернету

Сучасні веб-програми настільки ж складні, як і будь-які інші програмні програми, і часто створюються кількома людьми, які об'єднують зусилля для створення фінального продукту. У таких умовах, щоб підвищити ефективність, природно шукати правильні способи розподілу роботи на ділянки з мінімальними перетинами між людьми та підсистемами. Впровадження компонентного підходу (загалом) — те, як зазвичай вирішується таке завдання. Будь-яка компонентна система повинназменшуватизагальну складність через наданняізоляції, або природних бар'єрів, що приховують складність одних систем від інших. Хороша ізоляція також полегшує повторне використання та впровадження сервісних парадигм.

Як розбивати компоненти?

Ізоляція стилів у CSS

В рамках сьогоднішньої платформи немає ідеального і природного способу розбити CSS на компоненти (хоча інструменти на кшталт Sass можуть суттєво допомогти). Компонентна модель повинна пропонувати механізм для ізоляції одного підмножини CSS від іншого так, що правила не впливатимуть один на одного. До того ж, стилі компонента повинні застосовуватися тільки до безпосередніх частин компонента і ні до чого іншого. Легше сказати, ніж зробити!

Щоб передати стилі через кордон компонента ефективним чином тапри цьому захистити структуру компонента (наприклад, дозволити свободу зміни структури без впливу стилів), існує два загальні підходи, до яких багато хто схиляється: «часткова» стилізація з використанням псевдо-елементів та кастомні властивості (раніше відомі як «змінні» CSS). Якийсь час також розглядався супер-потужний крос-граничний селектор '>>>' (визначений у CSS Scoping), але сьогодні він загальновизнаний не найуспішнішою ідеєю, оскільки легко порушує ізоляцію компонентів.

З усіх підходів, що розглядаються на сьогодні, для стилізації майбутня «часткова» модель і поточна специфікація кастомних властивостей, здається, мають найбільші шанси реалізації. Ми розглядаємо кастомні властивості як новий ключовий член сімейства специфікацій веб-компонентів.

Інші підходи до ізоляції CSS стилів

Для повноти картини, області видимості та ізоляція CSS - це не така чорно-біла область, як могло здатися вище. Насправді, кілька минулих і поточних підходів пропонують варіанти обмеження сфери застосування та ізоляції з різною застосовністю до веб-компонентів.

CSS пропонує деякі обмежені форми ізоляції селекторів у специфічних сценаріях. Наприклад, правило @‍media групує набір селекторів разом і застосовує їх при настанні умов, відповідних медіа-контексту (наприклад, розмір або роздільна здатність в'юпорту, або медіа-тип - друк тощо); правило @‍page визначає деякі стилі, які можна застосовувати лише в контексті друку; правило @‍supports об'єднує разом селектори для застосування тільки коли реалізована підтримка специфічної CSS-функціональності - нова форма визначення наявності функціональності в CSS); запропоноване правило @‍document групує селектори для застосування тільки тоді, коли документ,якому завантажені стилі, відповідає умовам.

Області видимості CSS (спочатку написані як частина роботи над веб-компонентами) пропонують спосіб обмежувати застосовність CSS-селекторів всередині одного HTML-документа. Специфікація вводить нове правило @ scope, яке дозволяє селектору визначити корінь(і) області застосування і далі призводить до того, що застосування всіх селекторів всередині правила @ scope буде працювати тільки в піддереві цього кореня (а не на всьому документі). Специфікація дозволяє вказувати корінь області декларативно в HTML (наприклад, запропонований атрибут, поки реалізований тільки в Firefox; ця функціональність раніше була доступна в Chrome як експериментальна, але потім була повністю видалена). Деякі аспекти цієї функціональності (наприклад, :scope, визначений Selectors L4) також можуть застосовуватися для відносної оцінки селекторів в новому API запитів у специфікації DOM.

Тут важливо відзначити, що @‍scope встановлює тількиодно-спрямовануізоляцію кордонів: селектори, що містяться всередині @‍scope, обмежені цією областю, у той час як будь-які інші селектори (поза @‍scope) можуть спокійно проникати всередині @‍scope (хоча можуть бути по-різному упорядкованим каскадом стилів). Це дещо невдалий дизайн, тому що він не надає обмеження області та ізоляції від будь-яких стилів, які не знаходяться в підмножині @‍scope - весь CSS повинен, як і раніше, «добре стикуватися», щоб уникнути стилізації всередині чужого правила @scope. також малюнок @‍in-shafow-of від Таба, який краще узгоджений з моделлю захисту ізоляції компонентів.

Інша пропозиція обмеження видимості — це стримування CSS. Стримування області видимості — це меншою мірою для ізоляції стилів і селекторів і більшою міроюпро ізоляцію «композиції». Всередині властивості "contain" поведінка деяких можливостей CSS, які мають природне успадкування (у сенсі застосування від батьківського до дочірнього елемента в документі, наприклад, лічильники) буде блоковано. Основне застосування цього для розробників полягає в тому, щоб вказати, що деякі елементи передбачають суворе «стримування», так що композиція, що застосовується до цього елемента та його піддерева ніколи не торкатиметься композицію інших елементів документа. Ці обіцянки стримування (вказівки застосуванням властивості «contain») дозволяють браузерам оптимізувати композицію і малювання так, що «нова» композиція утримуваного піддерева потребує лише оновлення цього піддерева, а не всього документа.

У міру того, як реалізації технологій для веб-компонентів дорослішають серед браузерів і знаходять все більше публічного застосування, додаткові патерни стилізації та проблеми можуть виникнути; ми очікуємо подальших інвестицій та подальшого прогресу в різних пропозиціях у CSS для покращення стилізації веб-компонентів.

Ізоляція глобального об'єкту

Є ряд міркувань, які потрібно враховувати під час проектування компонентів із підтримкою ізоляції глобального об'єкта – особливо якщо ізоляція матиме на увазі захищені кордони (докладніше нижче). На сьогоднішній день ми очікуємо, що ізольовані компоненти не будуть повністю доступні доти, доки базовий набір специфікацій веб-компонентів не буде зафіксований (тобто, це «відкладено до наступної версії»). Однак, якщо ми витратимо деякий час на дослідження того, як ізольовані компоненти можуть виглядати, це може спрямувати поточну роботу в правильне русло. На деякі пропозиції справді варто звернути увагу.

ІзоляціяСвітовий об'єкт – це важливий нереалізований сценарій для веб-компонентів. А поки ми працюємо над реалізацією, можна, наприклад, покладатися на найуспішніший і найпоширеніший на сьогодні спосіб привнесення компонентності до веб: iframe-елемент.

Інкапсуляція елементів (iframe)

З гарними політиками безпеки та можливість вставляти кадр безшовно, використання iframe як модель для компонентів здається досить привабливим рішенням. Однак кількох властивостей бажаних у моделі веб-компонентів все ж таки не вистачає:

  • Глибока інтеграція. Iframe обмежує (і в основному повністю відключає) інтеграцію та взаємодію моделей між хостом та фреймовим документом. Наприклад, щодо хоста: фокус та модель виділення незалежна, а передача подій ізольована одним чи іншим документом. Для компонентів, які передбачають ближчу інтеграцію, підтримка такої поведінки не можлива без впровадження деякого «агента» у хостівому документі, який прокидав би відомості через кордон.
  • Розмноження світових об'єктів. Для кожної сутності iframe, створеної на сторінці, буде присутній унікальний глобальний об'єкт. Глобальний об'єкт та пов'язана з ним повна система типів не дешева у створенні і може призвести до споживання великої кількості пам'яті та надмірного навантаження на браузер. Множинні копії одного і того ж компонента, що використовуються на одній сторінці, не обов'язково повинні бути ізольовані одна від одної, на практиці наявність загального глобального об'єкта може бути бажаною, особливо якщо вони повинні підтримувати певний загальний стан.
  • Модель використання контенту хоста. Iframe не дозволяє повторного використання контентної моделі хост-елемента всередині кадрового документа. (Для простоти:контентна модельелемента – це його підтримуване піддерево елементів та тексту.) Наприклад, select-елементи має контентну модель, що включає option-елементи. Select-елемент, реалізований як компонента, захоче деяким чином взаємодіяти з дочірніми елементами.
  • Вибіркова стилізація. Безшовні iframe не працює з документами з різних джерел. Є явні ризики безпеки, якби це було дозволено. Основна проблема в тому, що безшовність контролюється хостом, а не фреймовим документом (фреймовий документ найчастіше є жертвою атак). Для компонента двозначна можливість включення «безшовності» (є чи ні) може бути надто дорогою; компоненти скоріше хотіли б вибірково приймати рішення, які стилі від хоста застосовні до вмісту (замість автоматичного успадкування всіх стилів, тобто це те, як працює безшовність).Загалом, питання, що має стилізуватися, має вирішуватися самим компонентом.
  • Виставлення API. Багато сценаріїв для веб-компонентів мають на увазі створення повноцінних кастомних елементів з власним виставленим набором API, семантикою відображення та керуванням життєвим циклом. Використання iframe обмежує розробника до роботи в рамках API iframe, з усіма його особливостями. Наприклад, ви не можете впливати на параметри самого iframe та його життєвий цикл.

Це все не вперше

Не можемо не відзначити, що в минулому кілька технологій вже було запропоновано і навіть запроваджено у спробі покращити роботу iframe у HTML та пов'язані можливості інкапсуляції. Втім, жодна з них не прижилася значною мірою в сучасному Інтернеті:

  • HTML Компоненти (1998) було запропоновано та впроваджено Microsoft, починаючи з IE5.5 (застаріли в IE10).Передбачалося використання декларативної моделі для додавання подій та API до хост-елементу (з урахуванням ізоляції) та парсингу компонентів у деякий “viewlink” (як “тіньовий DOM”). Було доступно два типи поведінки компонентів: одне тимчасово приєднувалося до елемента, інше динамічно прив'язувалося через CSS-властивість "behavior".
  • XBL (2001) та його спадкоємець XBL2 (2007) були запропоновані Mozilla як додаток до мови XUL для опису інтерфейсів. Це декларативна мова з двома можливостями зв'язування (схоже на HTML Компоненти від Microsoft), XBL також підтримував додаткові можливості доступу до контентної моделі хоста та створення контенту.

Сучасні веб-компоненти

Після провалу перших двох спроб, настав час спробувати запустити гру в компоненти знову, цього разу зайнявся Google. Використовуючи концепції, описані в XBL як стартову точку, монолітна компонентна система була розбита на колекцію будівельних блоків для компонентів. Ці будівельні блоки дозволили веб-розробникам експериментувати з окремими корисними можливостями до того, як загальне бачення веб-компонентів буде повністю визначено. Компонентність самого підходу та розробка окремих корисних можливостей дозволили просунутися ближче до успіху. Практично кожен може знайти у веб-компонентах щось корисне для своєї програми!

Ця нова хвиля веб-компонентів спричинила формування набору конкретних прикладів використання, які пояснюють, як існуючі вбудовані елементи працюють у рамках сьогоднішньої веб-платформи. Теоретично, веб-компоненти дозволять розробникам прототипувати нові типи HTML елементів з тією ж точністю і характерними рисами, як і у нативних елементів (на практиці забезпечення доступності в HTML єсьогодні особливо важким у досягненні).

Зрозуміло, що повний набір всіх технологій, необхідних для покриття всіх сценаріїв використання веб-компонентів, не буде реалізовано відразу в браузерах. Розробники браузерів працюють разом, щоб узгодити базовий набір технологій, який можна консистентно реалізувати, перш ніж рухатися до додаткових сценаріїв.

Веб-компоненти: наступне покоління

Як ми зазначили на початку цієї статті, побудувати повнофункціональні веб-компоненти – це велика пригода. Декілька ідей для розвитку та заповнення прогалин у поточному поколінні можливостей вже почало циркулювати серед розробників (це не повний список!):

Веб-компоненти – це поворотні моменти для Інтернету. Ми раді продовжувати підтримувати і робити свій внесок у цю пригоду. Діліться вашою думкою з нами у твіттері @msedgedev.