Пътуването на нашата система за проектиране към независимостта на рамката

„Преди две седмици обявихме работата, която вършим“ зад кулисите, за да изградим Clarity Core, независима от рамка система за проектиране, базирана на уеб компоненти. На високо ниво, това са нашите пет ключови цели и двигатели:

Моите колеги вече писаха за „нашият ангажимент за достъпност“ и усилията, които положихме като екип, за да изградим всеобхватна библиотека от компоненти. Днес ще разгледаме последната точка — независимост на рамката.

Какво е рамкова независимост?

Предната рамка е (най-общо казано) код, написан от външна група или организация, която се доставя с уеб приложение. Рамката обикновено обработва следните функции:

  • Маршрутизиране:превключване на „страници“ на приложението, без да ви отвежда до нова страница
  • Свързване на данни:когато промените информация на едно място, тя се показва правилно на друго
  • Управление на състоянието:поддържане на последователност на данните, така че всичко да остане според очакванията, когато преминавате от една страница към друга

Рамките със сигурност могат да направят повече от това, но това е същността на това, което правят. И има стотици от тях.

През последното десетилетие общността за разработка на предния край беше в центъра на истинска буря от рамки на JavaScript. Най-популярните рамки, които се използват днес, са React, Angular, Ember и Vue. А пейзажът беше доста каменист през последните 9 години, което накара мнозина да не вярват, че сегашното статукво ще остане такова много дълго. Последната част се нарича „умора на рамката“ или понякога „„умора на JavaScript““.

В ранните дни Clarity се обедини около Angular като начин да материализираме нашата система за проектиране в библиотечен комплекс, обвързани с данни компоненти и да обединим нашите продуктови екипи във VMware в общ технологичен стек. Това беше огромен успех за нас, тъй като видяхме, че по-голямата част от продуктите на VMware избират Angular и Clarity за изграждане на своите приложения.

Добрата новина е, че ще продължим да поддържаме и стимулираме приемането на Angular в цялата компания. Но по-добрата новина е, че нашите модели, услуги и компоненти вече ще бъдат достъпни за екипи, които разчитат на Vue, React, Ember, Elm или всяка друга рамка.

Убедени сме, че бъдещето на всички жизнеспособни библиотеки с компоненти е независимост от рамката и нашият план е да изпълним това убеждение.

Как ще направим това?

Нашият план е да доставим основен набор от уеб компоненти в npm пакет, който наричаме Clarity Core. В допълнение към тези компоненти, библиотеката Clarity Core ще съдържа помощници, миксини, услуги и помощни програми, които обикновено са полезни в „Clarity Angular“, Clarity Core и „Clarity Icons“.

Clarity Core ще се превърне в основна част от съществуващата Angular библиотека, която имаме, защото Clarity Angular ще използва повторно своите услуги и компоненти.

Защо уеб компоненти?

Към този момент уеб компонентите са „зрял уеб стандарт“. Те са достъпни в „почти всеки модерен браузър“ и поддръжката може да бъде пренасочена към браузъри, които нямат поддръжка.

Знаем, че персонализираните елементи могат да работят във всички браузъри, които поддържаме, и че това е подходящият момент да ги възприемем като основа за Clarity Design System.

Как това ще се отрази на библиотеката Angular?

Clarity Core изобщо няма да засегне потребителите на Clarity Angular. Дори когато компонентите и услугите на Clarity Core се използват като основна част от библиотеката Clarity Angular, екипите, които разчитат на Clarity Angular, няма да знаят или трябва да знаят, че тя е там.

Целта е това да има възможно най-малко въздействие върху съществуващите Clarity Angular приложения.

Едно Angular приложение не трябва да знае или да се интересува дали компонент Clarity е написан 100% на Angular или е изграден върху компонент Clarity Core.

Освен това Clarity винаги ще разчита на рамки, за да прави това, което правят най-добре, защото би било контрапродуктивно за нас да се опитаме да изградим отново рамка вътре в библиотека от уеб компоненти. Нашата рамка №1 във VMware е Angular, така че ние сме ангажирани в дългосрочен план да поддържаме и развиваме Clarity Angular.

Имах трудности с уеб компонентите в React. Как ми помага това?

През последните няколко месеца членовете на екипа на Clarity се задълбочиха в интегрирането на уеб компоненти с React приложения. В края на нашето пътуване идентифицирахме архитектура на „React wrappers“. Прегледахме тази архитектура с някои от най-добрите разработчици на React на VMware, за да сме сигурни, че имаме техния печат на одобрение, преди да продължим напред.

Как изграждате това?

Екипът на Clarity положи много усилия в проучването на най-добрия път напред за тази библиотека. В крайна сметка идентифицирахме три ключови атрибута, които искахме да запазим:

  • Архитектурата на библиотеката с компоненти на Clarity Core би била познатадостатъчно, че сътрудниците с опит в работата с Clarity Angular биха могли да допринесат за Clarity Core без стръмна крива на обучение.
  • API на текущите компоненти на Angular ще се прехвърлят възможно най-близо, за да помогнат за управлението на ситуации, при които текущият компонент на Angular ще се премести в библиотеката на уеб компонентите.
  • Кодът отдолу ще се придържа възможно най-близо до възникващите уеб стандарти, тъй като ние продължаваме да залагаме на уеб стандарти за бъдещето.

След няколко проучвания на различни възможности стигнахме до пет основи за архитектурата на Clarity Core. Имайте предвид, че следното е по-задълбочено гмуркане в техническите аспекти на Clarity Core. Ако това не е нещо, което ви интересува, моля, преминете към следващия въпрос.

  1. Машинопис

Typescript е супер набор от Javascript. Това е комбинация от проверка на типа и транспилер. Ако пишете код на Angular, без съмнение вече сте запознати с предимствата му. Пренасянето на това напред в библиотеката с компоненти на Clarity Core е фундаментално за целта кодовата база да остане позната на разработчиците, които са работили върху Clarity Angular в миналото.

2. Персонализирани свойства

„CSS Custom Properties“ са бъдещето и това е един голям залог, който правим върху уеб стандартите. Персонализирани свойства вече работят във всички основни браузъри.

Освен това персонализираните свойства са най-прекият начин за активиране на тематизиране в библиотека от капсулирани уеб компоненти на ShadowDOM.

3. Осветен елемент

„Осветен елемент“ е невероятно солидна и лека основа, върху която да се изгради библиотека от уеб компоненти. Lit се поддържа от екипа на Polymer в Google и нашето уважение към тази библиотека расте колкото повече работим с нея.

Освен че е много лека зависимост, Lit следва уеб стандартите — което беше важно за нас, защото вярваме, че уеб стандартите са бъдещето. Също така е страхотно да имате единствената си основна зависимост да бъде толкова тънък слой над кода, работещ в самия браузър.

Lit е повече от синтактична захар, но човек ще бъде извинен да го разглежда като удобен базов клас и нищо повече. Простотата и прозрачността на Lit също подкрепят желанието ни да запазим архитектурата възможно най-лесна за работа.

4. Минимално състояние

В нашето изследване искахме да сме сигурни, че компонентите на Clarity Core ще бъдат лесни за използване от продуктови екипи, работещи в Angular или React. За допълнителен кредит ние също се потопихме във Vue и няколко други рамки. Все пак ударихме малка неравностойност.

Изгледите на Angular и цикълът на откриване на промени са достатъчно различни от Flux архитектурата на React и Virtual DOM, така че начинът, по който разработчикът работи в една рамка, може да не следва непременно в другата рамка.

Разбира се, разработчиците на Angular имат NgRx и могат да го използват за управление на състоянието, съчетано с разширено (или някои биха казали правилно) използване на RxJS за внедряване на архитектурата Flux в техните Angular приложения. Но ние нямаме лукса да поддържаме само една реализация на архитектурата на приложението Angular.

Също така стана ясно в началото, че текущата библиотека от компоненти Clarity Angular предлага функционалност, свързана с Angular. Това представляваше функционалност, която нямаше смисъл да репликираме в библиотека от уеб компоненти.

За да бъдем по-конкретни, говорим за функции в Angular като реактивни форми, маршрутизиране и двупосочно свързване. Въпреки че повечето рамки имат собствено въртене на тези функции, стана ясно, че повечето рамки не винаги са били в съответствие по отношение на детайлите. В крайна сметка открихме, че няма едно идеално решение.

Нашият екип сега на шега нарича задачата за изграждане на рамки в рамки като „Frankenstein Angular“ и реши да не преизгражда „функции на рамката“ в библиотека от компоненти, независима от рамка.

Вместо това решихме, че най-добрият път напред е да приемем стратегия за „минимално поддържане на състоянието“.

Има някои функции на компонент, които би било уморително да включвате и изключвате от вашето приложение. Да бъдем „минимално поддържащи състоянието“ означава, че ние ще се справим с тези задачи вместо вас, ще ги проследим вместо вас и ще съобщим всички промени, така че да можете да поддържате състоянието на вашето приложение актуално, ако е необходимо.

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

Вследствие на това мрежата от данни в Clarity Core няма да управлява големи части от данни, както прави мрежата от данни в Clarity Angular. По същия начин съветник в Clarity Core също няма да управлява състоянието на своите страници и способността на потребителя да ги навигира по същия начин.

Въпреки че това може да е малко изненадващо за разработчиците, свикнали с монолитни компоненти на черна кутия, които поглъщат стотици редове JSON конфигурации, ние сме уверени, че това в крайна сметка ще бъде освобождаващо за разработчиците на приложения, защото поставя в ръцете им ниво на персонализиране, което други библиотеки не могат да съвпадат.

Той също така намалява изискванията за разработчиците да инвестират в изучаването на API на библиотека с компоненти - особено такава, която може да противоречи на избраната от тях рамка.

5. Намаляване чрез повторна употреба

В крайна сметка, Clarity Core ще бъде усъвършенстване на визията, която доведе до текущата библиотека от Angular компоненти.

Целта на тази нова инициатива не е да се дублират усилията с несвързана библиотека, която изисква отделна поддръжка, поддръжка и собствен екип. Истинската стойност на Clarity Core за нас е в това, което можем да абстрахираме и използваме повторно.

Ще има някои компоненти в Clarity Angular, които винаги ще бъдат изградени върху Angular – дори ако имат реплика в Clarity Core. Но много, ако не и повечето, компоненти в нашата Angular библиотека ще станат обвивки за компоненти на Clarity Core. Това ще помогне на екипа ни да направи разлика между управляваните от рамката функции и основните характеристики на компонентите, които доставяме.

Как да стигнем до там?

Предстои ни много работа и известни усилия за коригиране на текущата архитектура на Clarity, за да позволи нова библиотека от уеб компоненти.

Понастоящем нашата пътна карта за уеб компоненти изглежда по следния начин:

CSS Custom Properties–версия 3.0 (ноември-декември 2019 г.)

Рефакторингът на яснотата, за да се използват персонализирани свойства на CSS, е голяма задача — и такава, която завършихме само този месец! Започнахме, като доказахме, че можем да използваме персонализирани свойства във всички наши поддържани браузъри и надеждно да ги използваме в Shadow DOM.

Внедряването включваше изчистване на някои технически задължения в нашия SASS/CSS и след това значителна работа по създаване на всички персонализирани CSS свойства. Освен това се справихме с доставката по начин, който не е огромна промяна за екипи, които не се нуждаят от тематизиране на своите приложения или предпочитат да използват базираната на SASS тематика, която поддържаме днес през 3.0.

Но за да реализираме напълно предимствата на уеб компонентите в Clarity Core, трябва да отхвърлим SASS-базираната тематика в 3.0. Това означава, че започвайки от 4.0, персонализираните свойства на CSS ще бъдат единственият начин за тематизиране на приложения Clarity.

Преместване на икони за яснота към версия Core–3.0 (ноември-декември 2019 г.)

Миграцията на Clarity Icons е първият ни полигон за базирана на Lit архитектура и основно усилие за предоставяне на нашия набор от основни компоненти.

Основни компоненти–Q1 2020

След миграцията на иконите ще видим още основни компонентида влизат в битката.

Под „основополагащи компоненти“ имам предвид компоненти, от които зависят по-сложни компоненти. Не можем, например, да имаме „бутон с икона“ без икони или бутони.

Стратегически компоненти–2020

След като завършим нашите основни компоненти, планираме да преминем към „стратегически компоненти“през остатъка от 2020 г. Тази втора фаза на доставка на компоненти няма да представлява всички от компонентите в Clarity Angular днес, но ще бъдат доста голям брой от тях.

Когато определяме нещо като стратегически компонент, ние търсим компоненти, които отговарят на един от трите критерия:

  1. Компоненти, които задоволяват непосредствена нужда с компонент, до който екипите извън Angular, които се интересуват от използването на Clarity, нямат достъп днес...
  2. Компоненти, които увеличават библиотеката Clarity Angularс компоненти, които в момента библиотеката няма, и...
  3. Компоненти с висока стойносткоито не се репликират лесно с помощта на HTML и CSS Clarity, предлагани в момента.

Това може да означава, че не скачаме веднага във формулярите. Може би ще се съсредоточим върху нещо като избор на дата. Или магьосникът.

Всичко зависи от пресечната точка на нужда, стойност и наличност.

Насоки за принос–ноември 2019 г

Нашите насоки за приносще бъдат публикувани по-рано по време на нашата работа върху „основополагащите компоненти“. По природа тези компоненти ще бъдат по-прости в изпълнението. Ще има много компоненти на „ниско висящи плодове“, с които няма да се захванем веднага, тъй като се фокусираме върху основните компоненти и по-сложните стратегически компоненти. Това прави това плодородна почва за външни приноси и, ако искате да допринесете, „внимавайте за тези насоки за принос“!

React Wrappers (2019 на...)

И накрая, работата по основополагащия компонент ще представи нашата библиотека от „обвивки на реакция“за Clarity Core. Така че следете ги за предварителен преглед на това как планираме да поддържаме екипи на React с Clarity Core.

В заключителната

Когато става дума за компоненти, насочени към изграждане на уебсайтове и уеб приложения, смятаме, че бъдещето на мрежата е независимост от рамката. Това не означава, че рамките изчезват.

Но това означава, че библиотеките с компоненти, които разчитат на рамка за тяхното доставяне, ще станат по-малко полезни.

Като един от основателите на Clarity, мога да кажа, че този екип винаги е залагал на мрежата. Независимо дали става въпрос за ES2015/ES6, CSS3, SVG или HTML5, ние единодушно вярвахме, че най-добрият път напред е приемането на уеб стандарти.

Доказахме, че моментът е подходящ за уеб компоненти и се чувстваме уверени, че моментът е подходящ за Clarity Core.

Моля, дръжте под око нашето хранилище в github, докато работата по Clarity Core напредва! И „следете този RFC“ за повече подробности и дискусия относно архитектурата на следващия скок напред на Clarity.