Tři fáze designování komponent – 3.díl

30. 9. 2021

V této závěrečné fázi designování komponent se zaměříme na použitelnost CSS, zamyslíme se nad možným rozšířením o tabulkové direktivy a uvedeme si jejich hlavní výhody.

Pro ty z vás, které předchozí dva díly minuly, uvádím níže odkazy k přiblížení tématu:

CSS

Vstup do CSS pro začínajícího kodéra je obecně velmi přímočarý. Tento jazyk, tak jako ostatně celý FE ekosystém, je velmi přístupný pro začátečníky. Problém ale mnohdy nastává, pokud se má webová aplikace nebo web obecně škálovat, a na projektu se podílí více lidí či týmů. 

Do problémů se hlavně dostáváme v případech stylování a při následném užití reusable (znovupoužitelných) tzv. libs component, a jejich použitelnosti v kontextu užitých šablon. Proto se tomuto problému budeme v následujících několika řádcích věnovat primárně.

Mluvit o stylování jako takovém je také do jisté míry “tricky”, protože neexistuje ten jeden „správný přístup“, a to je hlavní kámen úrazu. Za posledních 25 let se totiž CSS přístupů vystřídalo kvantum a pro začátečníka to může znamenat velkou vstupní rozhodovací bariéru (např. v 1. díle zmíněná velmi oblíbená BEM metoda, CSS preprocesory, CSS-in-JS, dále různé CSS frameworky jako Bootrastrap,​​ Foundation, Semantic UI nebo například nejnovější přírůstek Tailwind CSS).

Tento článek je ale zaměřen na Angular ekosystém a demonstruje postupy na naší již existující tabulkové komponentě – B2aTableComponent. Cílem je tak ukázat jak stylovat libs komponentu v Angular projektu, která se zároveň přizpůsobí dané šabloně a skvěle funguje právě v kontextu Angular.

Při stylování naší libs komponenty se budeme držet následujících principů, které u nás využíváme při práci s Angular frameworkem:

  1. Definujeme styl jako globální, tzv. v root scope, a držíme se BEM principu deklarace.
  2. Používáme custom CSS properties, aby bylo možné různě zanořené deklarace jednoduše přestylovat bez používání CSS přetěžování nebo /deep/ deprecated hacku v případě scoped component (není náš případ).
    Custom CSS properties nám sami o sobě dávají jistou bezpečnost při možném refaktoringu. Definují části, které je možné upravit z venčí.
  3. Aplikujeme classes na host element komponenty (viz. 2. díl). A to primárně proto, abychom snížili množství renderovaného markupu.
    Také tímto můžeme snížit množství deklarovaných custom CSS properties, protože CSS class umístěna na host elementu lze jednoduše přetížit pomocí inline CSS stylu.
  4. V kódu striktně využíváme již existujících custom CSS properties definovaných šablonou (theme variables – v našem případě Nebular CSS custom properties) takovým způsobem, aby v případě, kdy tabulku použijeme u jiného projektu, se vzhledově přizpůsobila jeho barevnému schématu.

Principiálně jde o to, aby naše tabulka fungovala na základě požadavků daného kontextu (dle customer requirements) bez použití obskurních hacků. Nepotřebujeme podporovat IE, proto místo SCSS variables (ukázka použití u Material design components) používáme nativní custom CSS properties. Cílem je zmenšit scope kreativitu kodérů na minimum, svět je potom svobodnější jak říká klasik.

Root scope

Celá tato třídílná série je založena na iterativním principu vývoje. A cílem je čtenáři dokázat, že tento přístup je ten co možná nejvhodnější k dosažení nejlepšího výsledku tvorby libs komponent. Při návrhu přemýšlíme následovně:

  • Navrhneme obecný globální styling pouze pomocí CSS classes HTML elements.
  • Na základě následného používání vyhodnotíme složitost a „ukecanost“ dosavadního řešení. A zjednodušíme generovaný markup pomocí Angular komponent.

Tento iterativní přístup nám dá jasný obrázek o tom, jaké množství kódu je potřeba napsat bez použití Angular komponent a při jejím využití (viz. porovnání v 2. díle). U jednodušších komponent mnohdy Angular komponenty ponecháme stranou a využíváme pouze HTML elementy/CSS classes (HTML button). Díky tomuto přístupu můžeme generovaný kód zjednodušit na maximum. V opačném případě by to nešlo, protože možné zjednodušení by pro developera nebylo viditelné, tudíž prokazatelné.

Nejlépe se nám pracuje s globálními styly při tvorbě libs komponent, i když to nepůsobí uvěřitelně. Postupně jsme si nadefinovali takovou praxi, že když začínáme pracovat na nějaké libs komponentě, začneme s definicí CSS classes jako první, a to globálně s použitím BEM principu.

Pravidla pro definování jsou následující:

  1. Postupujeme podle BEM specifikace
    • Blok
      • .b2a-table (CSS class)
      • <b2a-table /> (budoucí Angular komponenta, ve které je použita .b2a-table CSS class na host elementu)
    • Element
      • .b2a-table__cell (CSS class)
      • <b2a-table-cell /> (budoucí Angular komponenta, ve které je použita .b2a-table__cell CSS class na host elementu. Název Angular komponenty už nepřebírá BEM konvenci, proto vždy použijeme pomlčku jako oddělovač.)
  2. Styl deklarujeme jako součást adresáře a importujeme následovně:
    • V hlavní komponentě B2aTableComponent deklarujeme styleUrls property společně s encapsulation:ViewEncapsulation.None.
      Existují ale i následující možnosti:
      • Importujeme samostatně v angular.json
      • Existuje i možnost vytáhnout styling do :root scope přes ::ng-deep hack. Nedoporučuji však používat! (::ng-deep je DEPRECATED, proto je dobré se tomuto postupu vyhnout, i když za něj neexistuje náhrada, a možná ani nikdy existovat nebude. Chtěl jsem však i přesto tuto možnost zmínit. Paradoxně je totiž tento přístup nejjednodušší z hlediska znovupoužitelnosti v novém projektu.)

Custom CSS properties

Zda použijete custom CSS properties nebo SCSS variables, to už záleží na vás. Obecně jsou custom CSS properties dynamičtější v tom smyslu, že lze definici stylu přetížit bez nutnosti prefixování dané variable (viz. material design). Další výhodou je možnost použití v Angular templates. Nevýhodou je naopak nutnost deklarovat velké možností properties a neexistující podpora v legacy prohlížečích typu IE11.

Použití v Angular template 

  • <b2a-table-row [style.–b2a-table__row-border-radius]=“‚5px'“></b2a-table-row>
  • Angular od verze 9 má nativní podporu pro deklarování custom CSS properties v šabloně, dříve tato možnost v této podobě neexistovala.

Použití v Angular SCSS

  • Deklarace je v SCSS souboru komponenty obecně následující:
    • .b2a-table__row { border-radius: var(–b2a-table__row-border-radius, 0); }
  • Dobrá vlastnost custom CSS properties je ta, že umožňují definovat fallback styling v případě (jako druhý parametr funkce var), kdy není custom property nadefinována v používaném scope. V našem případě je fallback hodnota rovná nule.
  • Nezmínili jsme dále možnost používat custom CSS properties přímo z SCSS souboru komponenty, ve které je b2a-table používána. Výsledek a použití je následující:

Host element

Koncept host elementu jsme v podstatě převzali ze specifikace pro Custom elements. Host element nám dává prostor pro umístění dodatečných informací jako například deklarování našich CSS classes.

Tyto použité CSS classes poté můžeme jednoduše přetížit při používání, je-li potřeba, a to bez nutnosti deklarování velkého množství custom CSS properties (top level CSS classes). Tento přístup je velmi elegantní pro koncového developera. Host elements jsme hojně využívali v 2. díle této série.

Theming

Jako náš komponent framework of choice je Nebular. Nabízí šablonovací systém a volitelně možnost deklarace Nebular variables jako root CSS properties. Můžeme tak definovat libovolné množství šablon, a rozlišit tím části naší aplikace (např. jiné barevné schéma). Jelikož tady existuje možnost takto elegantně měnit barevné schéma (a nejen to), byla by hloupost nepoužívat Nebular custom CSS properties pro naši libs komponentu. Resp. řekněme, že je to nutnost pro zachování nějaké konzistence. Proto v naší komponentě používáme jak custom CSS properties, tak sdílené, poskytované Nebular knihovnou.

DEPRECATED

  • SCSS @import.
    Nově máme k dispozici @use, které má jednu velkou přednost. A to takovou, že se importuje vždy pouze jednou bez ohledu na to, kolikrát je SASS module referencovaný v kódu. Deprecated ještě není, ale v budoucnu se tomu tak stane „Over the next few years Sass @import will be deprecated, and then removed.“
  • /deep/, >>>, a ::ng-deep.
    Doporučuji nepoužívat /deep/, >>>, a ::ng-deep pro přepisování stylů. A to z důvodu jedné velké nevýhody – jednak je to v Angularu a browseru deprecated (případ /deep/), ale hlavně při refaktoringu není šance zajistit zpětnou kompatibilitu (kdo a kde mohl kterou property přetížit).

Direktivy

Naše tabulka je definována kolekcí tabulkových komponent, které efektivně aplikují CSS classes pro co nejlepší použitelnost. Použití komponent se zdá být logickým krokem. V moderních frameworcích je komponenta základním building blokem pro tvorbu webu. Angular ekosystém je nicméně trochu odlišný a základní building blok je právě direktiva. Direktiva není nic jiného než komponenta bez šablony. Direktivy se primárně používají pro dekoraci již existujících elementů (o tom ale zase jindy). Této vlastnosti nyní plně využijeme a ukážeme si možnou variantu b2a-table direktiv aplikovaných na nativních table elementech.

Na první pohled se může zdát tvorba direktiv trochu zbytečná, nepotřebná a používání nativních table elementů jako zastaralý způsob. Table elementy ale mají jisté výhody, které nemusí být na první pohled zřejmé a z hlediska UX/UI/a11y požadavků zákazníka jsou mnohdy tou nejlepší volbou. Table elementy se hodí nejlépe na datové tabulky, mají built-in a11y (a11y jsme v naší sérií trestuhodně opomíjeli), lepší performance, defaultní styling atpod. Na druhou stranu nemusí být tak flexibilní jako tabulkové komponenty v případech, kdy je požadavek na umístění placeholder elementu při drag&drop apod.

Z výše uvedeného vyplývá, že je dobré mít implementované obojí varianty. Jako developer opravdu nechcete refaktorovat kód na nový interface v případech změny požadavků na UX/UI/a11y. Z těchto důvodu lze na následujícím obrázku vidět proveditelné řešení v podobě Angular direktiv, samotná implementace už však součástí této série není.

 Tabulka definována využitím Angular komponent:

Tabulka definována s využitím HTML table elements a Angular direktiv.
Tady lze v plné kráse vidět sílu Angular direktiv, kdy strukturu tabulky máme stejnou a pouze ji doplníme o nativní elementy. Tento princip využívá Angular Material Table components:

Závěr

Tímto dílem celou sérii končíme a věřím, že se podařilo demonstrovat sílu iterativního přístupu ve vývoji při využití starých dobrých HTML elements a CSS classes s případnou transformací do Angular komponent či direktiv. V závěru jsme si předvedli možné vylepšení v podobně b2a-table direktiv, které mají validní use-case, stejně jako komponenty.

Tak jako v každém díle si implementaci můžete prohlédnout na našem B2A Github repositáři.

< Zpět na VÝPIS AKTUALIT

Hledáme lidi s talentem a zapálením pro věc.

Zobrazit PRACOVNÍ nabÍdky
Základní informace
B2A Software Development, s.r.o.
Lešetín II 651
760 01 Zlín

IČ: 03322220
Office
tř. Tomáše Bati 269
760 01 Zlín
Zobrazit na mapách
(c) 2022 B2A Software Development s.r.o.
menu-circlecross-circle
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram