Salesforce Lightning Web Components – tworzenie komponentów “lightning look and feel“

Interfejs użytkownika LWC – jak go budować?

Interfejs Lightning Web Components możemy zbudować na kilka sposobów:

• przy wykorzystaniu zewnętrznych bibliotek;
• przy użyciu standardowych tagów html;
• przy użyciu standardowych komponentów LWC. (https://developer.salesforce.com/docs/component-library/)

Każdy ze sposobów ma swoje wady i zalety. Zewnętrzne biblioteki są bardzo rozbudowane oraz zawierają wiele różnorodnych komponentów. Niestety, nie zawsze udaje się w intuicyjny sposób wykorzystać je w LWC. Narzucają również określony styl i wygląd.

Standardowe tagi html są bardzo łatwe w użyciu i w pełni kompatybilne z LWC. Łatwość użycia jest zarazem wadą, gdyż zazwyczaj oznacza bardzo ograniczone zastosowanie. Do wad należy też dodać styl. Z kolei standardowe komponenty – a zwłaszcza ich wygląd – na pewno nie zostaną zaakceptowane w projekcie.

Najlepszym rozwiązaniem do budowania interfejsu użytkownika są komponenty dostępne źródłowo we frameworku. Ich lista jest naprawdę spora, a dzięki możliwościom, które dają, można spełnić  większość wymagań projektowych. Chcemy zbudować responsywny formularz dostępny zarówno na telefonie komórkowym, tablecie, jak i desktopie? Nie ma problemu – wystarczy użyć lightning-layout. Ten sam efekt można oczywiście osiągnąć, używając innych technik – chociażby css i flex. Pytanie tylko, czy warto? Jeżeli chcemy zaimplementować customową walidację na polach, możemy użyć lightning-input oraz setCustomValidity.

Dużą zaletą komponentów z biblioteki LWC jest ich wygląd. W standardzie otrzymujemy interfejs spójny wizualnie z całą Platformą Salesforce. Wystarczy odrobina wysiłku ze strony nas – developerów Salesforce, aby użytkownik nie odczuł różnicy pomiędzy pracą na standardowych formularzach a pracą na w pełni customowych rozwiązaniach.

Implementacja własnego komponentu – od czego zacząć?

Mimo iż biblioteka komponentów LWC jest spora, nie zawsze znajdziemy w niej rozwiązanie  spełniające wszystkie nasze oczekiwania. Bardzo często zdarza się, iż dostępny komponent spełnia nasze wymagania funkcjonalne, ale wizualnych już nie. Niestety, shadow dom uniemożliwia nam nadpisanie css. W takich przypadkach jesteśmy zmuszeni zejść poziom niżej i zaimplementować własny komponent.

Od czego zacząć? Jakimi wytycznymi się kierować?

1. Skoro już piszemy własny komponent, niech będzie on reużywalny. Dzięki temu dodatkowa praca zwróci się, gdy wykorzystamy komponent w następnych projektach.
2. Nie chcemy zmieniać wyglądu całego interfejsu, więc nasz komponent musi wkomponować się w jego obecny styl.
3. W zespole są osoby, które znają komponenty LWC, używają ich w codziennej pracy, więc API naszego komponentu powinno być w pełni kompatybilne, zarówno funkcjonalnie, jak i w warstwie nazewnictwa.

Implementacja własnego komponentu krok po kroku

Naszym celem jest zbudowanie komponentu typu lightning-select. W bibliotece LWC istnieje jego odpowiednik – lightning-combobox, ale jego zachowanie i wygląd nie zawsze są wystarczające dla bieżących potrzeb.

Krok pierwszy – budowa szablonu html

Na szczęście, nie musimy zaczynać projektowania naszego komponentu od zera. Z pomocą przychodzą nam Lightning Design System oraz Components Blueprint (https://www.lightningdesignsystem.com/components/overview/).

Strona ta pokazuje html wszystkich komponentów z biblioteki LWC oraz wiele innych. Co najważniejsze, wszystkie komponenty są ostylowane klasami dostępnymi standardowo wewnątrz komponentów LWC.

obraz 1 – customSelect.html

Najprostszy layout tworzymy w kilka minut. Szablon kopiujemy z components blueprint. Następnie wstawiamy zmienne z modułu js, podpinamy obsługę onchange, dodajemy iterację na option i gotowe.

Krok drugi – moduł js

Do modułu dodajemy publiczne zmienne: label, options oraz value. Implementujemy też metodę handleChange, która będzie wywoływała event o nazwie change.

Moduł js wygląda następująco:

obraz 2 – moduł js 

Stworzenie najprostszego komponentu typu select zajmuje maksymalnie 10 minut. Reszta zależy już tylko od stopnia złożoności wymagań.

Krok trzeci – rozbudowa komponentu

Do komponentu chcemy dodać możliwość zarządzania wyglądem. W tym miejscu należy pamiętać o wykorzystaniu dobrych praktyk i zachowaniu spójności nazewniczej z biblioteką LWC, więc dodajemy publiczny properties: “variant”.  Implementujemy też obsługę wraz z możliwą wartością: “label-hidden”. Dodamy też opcję dodawania pustej domyślnej wartości.

Szablon html:

obraz 3 – szablon html 

Moduł js:

obraz 4 – moduł js 

Ustawienie variant = “label-hidden” spowoduje wyświetlenie samego komponentu select, bez labelki. Zachowanie jest tożsame z komponentami dostępnymi w bibliotece Lightning Web Components. Dodanie atrybutu add-empty-value spowoduje dodanie pustej wartości do dostępnych opcji.

Zbudowany komponent nie jest oczywiście kompletny. Należy do niego dodać na przykład obsługę ustawiania i reakcję na zmiany value oraz walidację.

Budowa własnych komponentów jest prosta i przynosi wiele korzyści – mam nadzieję, że Was o tym przekonałem. Zachęcam, aby podczas ich tworzenia pamiętać o ich reużywalności oraz spójności – przestrzeganie tych zasad zaowocuje w kolejnych projektach.