Kontynuuję serię publikacji, w których dzielę się z Wami moimi sprawdzonymi sposobami na projektowanie rozwiązań w Lightning Web Components w Salesforce. W poprzednim artykule Zastosowanie fabryk w Salesforce Lightning Web Components – dobre praktyki pisałem o tym, jak powinna wyglądać i do czego ma służyć fabryka oraz dlaczego warto jej używać. Tym razem skupię się na budowaniu interfejsu użytkownika.

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

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 _krok2

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 _krok3

obraz 3 – szablon html 

Moduł js:

obraz 4 - moduł js _krok3

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.

Autor
  • Łukasz Czerwiński
  • Salesforce Developer
  • Swoją przygodę z programowaniem zaczynał od Delphi 7. Kolejnym krokiem w świecie kodowania był C# i niedługo póżniej Java oraz javascript. Obecnie zajmuje się głównie technologiami front-endowymi, a znajomość różnych języków programowania, technologii i frameworków, takich jak: ASP.NET, JSF, PrimeFaces, AngularJS czy Lightning, ułatwia mu pracę i dobór odpowiednich narzędzi do powierzonych zadań. Prywatnie miłośnik jazdy na rowerze, który wyznaje zasadę: kilometry same się nie zrobią.

Opracowanie redakcyjne:
Ania Sawicka
Opracowanie redakcyjne
Ola Pasek
Korekta językowa
Podobał Ci się mój artykuł?
Jeśli nie widzisz formularza, spróbuj wyłączyć adblocka.

Jeśli tak, zapraszam Cię do grona najlepiej poinformowanych czytelników bloga. Dołącz do naszego newslettera, a nie ominą Cię żadne nowości.