Развитието на фронтенд уеб разработките се движи с бурно темпо. Това става очевидно от безбройните статии, уроци и постове в Twitter, оплакващи състоянието на това, което някога е било един доста прост технологичен стек. В тази статия ще обсъдим защо уеб компонентите са един чудесен инструмент за предоставяне на висококачествено потребителско изживяване без нуждата от употреба на сложни рамки или стъпки за изграждане и то без риск да остареят в технологично отношение (най-вероятно винаги ще са актуални).
В следващите статии от тази поредица от пет части ще се потопим по-дълбоко във всяка от спецификациите.
Тази поредица предполага, че имате основно разбиране за HTML, CSS и JavaScript.
Какво представляват уеб компонентите?
Уеб компонентите се състоят от три отделни технологии, които се използват заедно:
- Персонализирани елементи. Съвсем просто, това са напълно валидни HTML елементи с персонализирани шаблони, поведения и имена на маркерите (например <one-dialog>), създадени с набор от JavaScript APIs. Персонализираните елементи са дефинирани в спецификацията на HTML Living Standard .
- Shadow DOM. Способен да изолира CSS и JavaScript, има почти същото поведение като <iframe>. Това е дефинирано в спецификацията на Living Standard DOM .
- HTML шаблони. Това са потребителски дефинирани шаблони в HTML, които не се изобразяват, докато не бъдат извикани. В <template> маркера е определено в спецификацията на HTML жизнено равнище .
Това е, което съставлява спецификацията на уеб компонентите.
Уеб компонентите обикновено са достъпни във всички основни браузъри, с изключение на Microsoft Edge и Internet Explorer 11, но съществуват полифили за запълване на тези пропуски .
Да наречем уеб компонент което и да е от гореспоменатите е технически точно, тъй като самият термин е малко пре-експониран. В резултат на това всяка от технологиите може да се използва самостоятелно или да се комбинира с някоя от останалите. С други думи, те не се изключват взаимно.
Персонализирани елементи
Както подсказва името, персонализирани елементи са HTML елементи, също като <div>, <section> или <article>, които може да се именуват от нас и след това дефинирани чрез API-то на браузъра. Персонализираните елементи са точно като стандартните HTML елементи – имена обградени в ъглови скоби – с изключение на това правило, че винаги трябва да имат тире в себе си, като например <news-slider> или <bacon-cheeseburger>. За напред създателите на браузъри се ангажират да не създават нови вградени HTML елементи съдържащи тире в имената им, за да се предотвратят бъдещи конфликти.
Персонализираните елементи съдържат своя собствена семантика, поведение и име и могат да се използват в различните браузърите.
В този пример ние дефинираме <my-component> като наш собствен HTML елемент. Разбира се, това не прави кой знае какво, но това е първият и основен градивен елемент на всеки персонализиран елемент. Всички потребителски елементи трябва по някакъв начин да разширят, HTMLElement за да бъдат регистрирани в браузъра.
Персонализираните елементи съществуват без рамки на трети страни и доставчиците на браузъри са посветени на продължаващата обратна съвместимост на спецификацията, като всичко това гарантира, че компонентите, написани съгласно спецификациите, няма да страдат от нарушаване на промените в API. Нещо повече, тези компоненти обикновено могат да се използват нестандартно с най-популярните рамки днес , включително Angular, React, Vue и други и то с минимални усилия.
Shadow DOM
Shadow DOM представлява капсулирана / изолирана версия на DOM. Това позволява на авторите на елементите ефективно да изолират DOM фрагменти един от друг, включително всичко, което може да се използва в тях като CSS селектор и стиловете свързани с тях. Обикновено всяко съдържание вътре в обхвата на документа се нарича light DOM, а всичко вътре в корена на сянката (Shadow) се нарича DOM на сянката.
Когато се използва light DOM, даден елемент може да бъде селектиран чрез използване на document.querySelector(‘selector’) или чрез насочване към дъщерните елементи на всеки елемент чрез използването на element.querySelector(‘selector’); по същия начин дъщерните на корена в “сянка” могат да бъдат селектирани чрез shadowRoot.querySelector където shadowRoot е препратка към фрагмента на документа – разликата между двете е, че дъщерните елементи на корен в “сянка” няма да могат да бъдат селектирани от light DOM.
Например, ако имаме корен в сянка с елемент <button> във вътрешността, извикването със shadowRoot.querySelector(‘button’)ще върне нашия бутон, но нито едно извикване на селектора на заявки на документа няма да върне този елемент, защото той принадлежи на различен DocumentOrShadowRoot екземпляр. Селекторите на стиловете работят по същия начин.
В това отношение Shadow DOM работи като нещо като, <iframe> където съдържанието е “отрязано” от останалата част на документа; обаче съществена разлика е че, когато създаваме корен в сянка, ние все още имаме пълен контрол върху тази част от нашата страница, но обхванат в контекст. Това наричаме капсулиране.
Ако някога сте писали компонент, който използва повторно същия id или разчита на CSS-in-JS инструменти или CSS стратегии за именуване ( като BEM ), Shadow DOM има потенциала да подобри вашето изживяване като разработчици.
Представете си следния сценарий:
Освен псевдокода на <#shadow-root> (който се използва тук за демаркиране на границата на сянката, която няма HTML елемент), HTML кода е напълно валиден. За да прикрепим корен в сянка към възела по-горе, ще изпълним нещо като:
Коренът в сянка може също да включва съдържание от съдържащия го документ, като използва <slot>елемента. Използването на слот ще прехвърли потребителското съдържание от външния документ на определено място във вашия корен в сянка.
HTML шаблони
Подходящо именуваният HTML <template> елемент ни позволява да извадим повторно използваемите шаблони на код в нормален HTML поток, който няма да бъде изобразен веднага, но може да бъде използван по-късно.
Примерът по-горе няма да изобрази никакво съдържание, докато скриптът не консумира шаблона, не създаде инстанция на кода и не каже на браузъра какво да прави с него.
Забележете, че този пример създава шаблон ( <template id=“book-template“>) без употребата на друга технология за уеб компоненти, илюстрирайки отново, че трите технологии в стека могат да се използват както независимо така и колективно (съвместно).
Привидно потребителят на услуга, която използва API на шаблона, може да напише шаблон с всякаква форма или структура, които могат да бъдат създадени по-късно. Друга страница от сайта, който разработваме може да използва същата услуга, но структурирайки шаблона по следния начин: