Zakładam, że przeczytałeś już ten artykuł: Dyrektywy

Czemu? Ponieważ jest to kolejna część i biorąc pod uwagę, że komponenty i dyrektywy mają te same opcje, tutaj wymienimy się tylko o specyfice komponentów :-). Mówiąc dokładniej, komponent jest podklasą dyrektywy z większymi możliwościami (przynajmniej szablonem).

Więc chcesz stworzyć nieistniejący element? Ok, masz rację, potrzebujesz komponentu.

@Składnik

Dzięki temu dekoratorowi klasa jest rozpoznawana jako składnik.

Opcje

Wszystkie opcje zdefiniowane dla dyrektywy są dostępne dla składnika. Więc tutaj wymieniamy tylko opcje specyficzne dla komponentu.

changeDetection?: ChangeDetectionStrategy

Zrobię o tym artykuł. Ale aby mieć minimalną informację, musimy wiedzieć:

• Wartość domyślna to ChangeDetectionStrategy.Default
• Pozwala określić, kiedy nasz komponent jest odświeżany

Połączyłem te 2 opcje, ponieważ musisz zdefiniować jedną z nich. Jeśli jeden jest zdefiniowany, nie musisz definiować drugiego.

Który wybrać?

Jeśli jesteś purystą, zawsze powinieneś wybrać templateUrl (separacja wątpliwości). W przeciwnym razie możesz skorzystać z przewodnika po stylu Angular:https://angular.io/guide/styleguide#extract-templates-and-styles-to-their-own-files

Z szablonem:

Z adresem URL szablonu:

Osobiście używam obu. Jak wybrać? Cóż, jeśli mój szablon jest krótkim szablonem wbudowanym i jest łatwy do odczytania w pliku ts, wybieram opcję szablonu, w przeciwnym razie używam templateUrl. Pamiętaj, że Twój kod powinien być zawsze łatwy do odczytania/zrozumienia, co jest kluczem do jakościowego kodu.

styleUrls?: string[] | style?: ciąg[]

Te dwie opcje mogą być używane razem. ALE naprawdę nie polecam korzystania z drugiego. Czemu?

• Po pierwsze, jeśli używasz dobrego IDE, nie będziesz mieć dla niego autouzupełniania. Często css jest jak koszmar dla programistów, więc autouzupełnianie jest dobrą pomocą.
• Po drugie, globalnie style są trudne do utrzymania, więc lepiej jest je scentralizować w plikach arkuszy stylów.

Ze stylami:

Z adresami URL stylu:

Oba dają ten sam wynik.

animacje?: dowolna[]

Myślę, że lepiej będzie zrobić własny artykuł :-)

enkapsulacja?: ViewEncapsulation

To ciekawa opcja, ponieważ nie musimy wybierać raz na zawsze jako wytycznej dla kodu. Wszystkie wartości mogą być użyte w aplikacji i nie jest to zły wybór. Zależy to od przypadku użycia lub potrzeb związanych z komponentem. Jaka jest więc specyfika każdego z nich?

• ViewEncapsulation.Emulated: jest to wartość domyślna, ALE jeśli nie podano opcji styleUrls lub styles, przełącza się na ViewEncapsulation.None podczas kompilacji. Styl obejmuje zakres od elementu hosta do elementu potomnego. WSKAZÓWKI: w arkuszu stylów, jeśli chcesz wystylizować komponent hosta, możesz użyć selektora hosta {}.
• ViewEncapsulation.None: bez zakresu, bez enkapsulacji. Wszystko jest dostępne i można je obejść. WSKAZÓWKI: jeśli chcesz nadać styl elementowi nadrzędnemu, użyj selektora komponentów.
• ViewEncapsulation.ShadowDom: hermetyzuje komponent w domku cienia. Mówiąc najprościej, nic w domu cieni nie może wpłynąć na nic poza nim. Po więcej informacji:https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM. Obecnie większość przeglądarek to obsługuje.

Pozwala na zastąpienie domyślnych ograniczników interpolacji. Wartość domyślna to {{}}. Interpolacja pozwala na umieszczenie kodu ts wewnątrz szablonów HTML.

Jeśli uda mi się uciec z radą: nie zmieniaj tego. Może ci się to nie podoba, może chcesz użyć własnego, ALE nie zapominaj, że pracujesz z innymi programistami i większość z nich używa domyślnego. Niech Twój kod będzie łatwy do odczytania/zrozumienia. Czy naprawdę chcesz tracić na to czas swojego zespołu?

Dzięki interpolacji możemy przekazać zmienne maszynopisowe do szablonu HTML.

zachowaćbiałe spacje?: boolean

Jeśli prawda, zachowaj wszystkie niepotrzebne spacje ze skompilowanego szablonu. W przeciwnym razie zostanie usunięty, z wyjątkiem tekstu wewnątrz <pre> lub <textarea>, ponieważ spacje są znaczące.

Wniosek

Mam nadzieję, że pomoże to w tworzeniu własnych komponentów i lepszym zrozumieniu subtelności opcji komponentów. Jeśli masz jakieś pytanie lub temat, na który chcesz uzyskać wyjaśnienie, nie wahaj się :-) w przeciwnym razie dzięki za przeczytanie.

Następny rozdział: Moduły