Angular – dekorator @HostBinding

Czołem!
Jak już zauważyłeś czytelniku, zmienił się wygląd bloga. Jest to związane z aktywizacją, która nastąpi w drugiej połowie lutego – wpisy gościnne, regularne wpisy, między innymi z tworzeniem jakichś ciekawych komponentów – będzie się działo w każdym razie , stay tuned 😉

Tyle tytułem wstępu. W tym artykule, zapraszam Cię do zapoznania się z dekoratorem @HostBinding, który zaprezentuję na jakimś ciekawszym przykładzie.

Dekorator @HostBinding

Dekorator @HostBinding może przyjąć jeden parametr, np. propercję hosta (czyli komponentu), do której możemy się podpiąć. Przykładem takiej propercji, może być np id.

Rozważmy przykład, w którym chcemy nadać inne ID każdemu elementowi z listy:

Link do StackBlitz z powyższym przykładem: LINK

 

Oczywiście powyższy sposób zadziała, każdy komponent product-list-item będzie mieć inne ID. Jednak problem się pojawia, jeśli na tym samym widoku pojawi nam się kolejny *ngFor z taką listą. W tym przypadku, zaczną nam się dublować te ID, ponieważ znowu będą numerowane od 0 do 4.

W takiej sytuacji, przychodzi z pomocą dekorator @HostBinding. Komponent sam sobie nada atrybut ID, wg logiki którą mu przekażemy.
Spójrzmy, jak to zrobić teraz bardziej elegancko, aby każda nowa instancja komponentu ProductListItem, miała zawsze  inne ID…i to niezależnie od widoku!
Możemy to zakodować następująco:
W powyższym przypadku, korzystamy z dekoratora HostBinding i nakładamy na naszego hosta (nasz komponent ProductListItem) property id o zadanej wartości. Skorzystałem tutaj z pola statycznego, które jest współdzielone przez instancje klasy.
Co ciekawe – nie musiałem przekazać żadnego parametru do HostBinding! Powyższy przykład, możesz również zapisać następująco, z dowolną nazwą pod którą przypiszemy ID w klasie:
Dzięki temu zabiegowi, każdy nowo-powstały komponent, ma już unikalne ID. Teraz możemy tworzyć dowolną ilość naszego ProductListItemComponent, kompletnie się nie martwiąc, że ID mogą się powtórzyć:

Ostatni komponent oczywiście będzie miał id „product-list-item-10”.
Link do StackBlitz z powyższym przykładem: LINK

 

Spójrzmy, jakie jeszcze są możliwości skorzystania z @HostBinding:

 

Jak widzisz na powyższej grafice, HostBinding pozwala nam się podpiąć łatwo pod klasy hosta, style, atrybuty, propercje.
Przykładowo, możemy nadać klasę hostowi, na podstawie jakiegoś warunku logicznego. Poza tym, przypisane pola do HostBindingów są polami klasy, więc możemy sięgać po nie w logice naszego komponentu. Można również nadać parę klas na raz – wystarczy rozdzielić je spacją w stringu i przypisać do @HostBinding(‚class’).

 

Dekorator często pomaga też w sytuacjach, kiedy logika danego komponentu zaczyna wypływać na zewnątrz. Często widzę sytuacje, że na komponent jest nałożony [ngClass] aby dodać klasę na podstawie jakiegoś warunku, który równie dobrze mógłby być obsłużony poprzez HostBinding wewnątrz klasy komponentu, na którym chcemy użyć ngClass. Profit jest nieoceniony – kolejne instancje komponentów nie wymagają znowu nałożenia ngClass i powtarzania kodu.
Dodatkowo, @HostBinding możemy również wykorzystywać w dyrektywach. Zatem jak widzisz, ten dekorator ma potężne możliwości – wyłącznie od Ciebie zależy, jak je wykorzystasz 😉

2 Comments

  1. Bartosz Jasiewicz

    W przypadku nadawania klasy , czyli opcji nr 4 od góry, właściwie jaka jest różnica jak zrobi się to poprzez ten dekorator:
    @HL(‚class’) someClass = ‚my-class’;
    a poprzez zwykłe przypisanie elementowi klasy np.

    Domyślam się, że dzięki dekoratorowi można ją wg uznania zmienić w komponencie, ale jeśli nie ma potrzeby jej zmieniać, tylko ma być przypisana tak po prostu, na stałe, to czy są jakieś różnice w dwóch podejściach?

  2. Pingback: Angular Tips & Tricks cz. VI – Angular.love

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *