Прилагане на компонентен подход в уеб Преглед на уеб компонентите

Съдържание:

Инжектиране на компоненти: стара дизайнерска практика, нова в мрежата
Как да се раздели на компоненти
Не е за първи път: Предишни подходи за инжектиране на компоненти
Съвременни уеб компоненти
Уеб компоненти: следващото поколение

Инжектиране на компоненти: стара дизайнерска практика, нова в мрежата

Съвременните уеб приложения са толкова сложни, колкото всяко друго софтуерно приложение и често се създават от множество хора, които работят заедно, за да създадат крайния продукт. При такива условия, за да се повиши ефективността, е естествено да се търсят правилните начини за разделяне на работата на участъци с минимални пресичания между хора и подсистеми. Прилагането на компонентен подход (като цяло) е начинът, по който обикновено се решава такава задача. Всяка компонентна система трябва данамалявацялостната сложност чрез осигуряване наизолацияили естествени бариери, които скриват сложността на някои системи от други. Добрата изолация също така улеснява повторното използване и прилагането на парадигми на услугите.

Как да разделим на компоненти?

Изолиране на стил в 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, създаден на страницата, ще има уникален глобален обект. Глобалният обект и свързаната с него пълна система от типове не са евтини за създаване и могат да консумират много памет и да натоварят браузъра. Множество копия на един и същ компонент, използвани на една и съща страница, не е необходимо да бъдат изолирани едно от друго, на практика може да е желателно да има общ глобален обект, особено ако те трябва да поддържат някакво споделено състояние.
Модел на използване на съдържанието на хоста. Вградената рамка не позволява моделът на съдържанието на хост елемент да бъде използван повторно в рамките на документ с рамка. (За простота:Моделътсъдържание на елементе неговото поддържано поддърво от елементи и текст.) Например избраните елементи имат модел на съдържание, който включва елементи на опции. Избран елемент, внедрен като компонент, ще иска да взаимодейства с дъщерни елементи по някакъв начин.
Селективен стайлинг. Seamless iframe не работи с документи от различен произход. Има ясни рискове за сигурността, ако това бъде позволено. Основният проблем е, че "seamless" се контролира от хоста, а не от рамковия документ (рамковият документ е по-често жертва на атаки). За компонент двустойната способност за активиране на "безпроблемно" (независимо дали или не) може да бъде твърде скъпа; компонентите по-скоро избирателно решават кои стилове от хоста се прилагат към тяхното съдържание (вместо автоматично да наследяват всички стилове, което е начинът, по който работи безпроблемността).По принцип въпросът какво трябва да бъде стилизирано трябва да бъде решен от самия компонент.
Експозиция на API. Много сценарии за уеб компоненти включват създаване на пълноценни персонализирани елементи със собствен открит набор от API, семантика на дисплея и управление на жизнения цикъл. Използването на iframe ограничава програмиста да работи в API на iframe с всички негови функции. Например, не можете да промените параметрите на самия iframe и неговия жизнен цикъл.

Не е за първи път

Не можем да не отбележим, че няколко технологии вече са предложени и дори внедрени в миналото в опит да се подобри HTML iframe и свързаните с него възможности за капсулиране. Нито един от тях обаче не е пуснал корени в голяма степен в съвременната мрежа:

HTML Components (1998) бяха предложени и внедрени от Microsoft, започвайки с IE5.5 (отхвърлен в IE10).Предполагаше се да се използва декларативен модел за добавяне на събития и API към хост елемента (като се вземе предвид изолацията) и анализиране на компоненти в някаква „прегледна връзка“ (като „shadow DOM“). Бяха налични два типа поведение на компонента: единият беше временно прикрепен към елемент, другият беше динамично прикрепен чрез свойството CSS „поведение“.
XBL (2001) и неговият наследник XBL2 (2007) бяха предложени от Mozilla като допълнение към езика XUL за описание на интерфейси. Това е декларативен език с две възможности за обвързване (подобно на HTML компонентите на Microsoft), XBL също поддържа допълнителен модел за достъп до съдържание на хост и възможности за генериране на съдържание.

Съвременни уеб компоненти

След неуспеха на първите два опита, беше време да опитате отново да пуснете играта в компоненти, този път с Google. Използвайки концепциите, описани в XBL като отправна точка, монолитната компонентна система беше разбита на колекция от компонентни градивни елементи. Тези градивни елементи позволиха на уеб разработчиците да експериментират с отделни полезни функции, преди цялостната визия за уеб компонента да бъде напълно дефинирана. Компонентният характер на самия подход и разработването на отделни полезни функции направи възможно приближаването към успеха. Почти всеки може да намери нещо полезно в Web Components за своето приложение!

Тази нова вълна от уеб компоненти доведе до набор от конкретни случаи на употреба, които обясняват как съществуващите вградени елементи работят в днешната уеб платформа. На теория уеб компонентите ще позволят на разработчиците да създават прототипи на нови типове HTML елементи със същата прецизност и характеристики като нативните елементи (на практика достъпността в HTML еособено трудно за постигане днес).

Ясно е, че пълният набор от всички технологии, необходими за покриване на всички сценарии за използване на уеб компоненти, няма да бъдат внедрени в браузърите веднага. Разработчиците на браузъри работят заедно, за да се договорят за основен набор от технологии, които могат да бъдат внедрени последователно, преди да преминат към допълнителни сценарии.

Уеб компоненти: следващото поколение

Както отбелязахме в началото на тази статия, изграждането на напълно функционални уеб компоненти е голямо приключение. Няколко идеи за надграждане и запълване на пропуските в текущото поколение функции вече започнаха да циркулират сред разработчиците (това не е пълен списък!):

Уеб компонентите са повратна точка за мрежата. Ние сме развълнувани да продължим да подкрепяме и допринасяме за това приключение. Споделете вашите отзиви с нас в twitter @msedgedev.