W tym momencie mogłeś już słyszeć o komponentach dynamicznych, które są bardzo przydatne do tworzenia bardziej dynamicznych aplikacji. Pozwalają nam na dynamiczne ładowanie komponentów w czasie wykonywania, w zależności od jakiejś niestandardowej logiki, bez konieczności tworzenia komponentu, który jest nadęty mnóstwem ngIf.

Jeśli nie słyszałeś jeszcze o Dynamic Components, proponuję obejrzeć wykład Shmueli Jacobsa na Angular Connect:

W mojej codziennej pracy buduję system, który jest jak CRM zarządzający różnymi produktami, które mają wspólną część podstawową, ale także pewne specyficzne dla produktu elementy. Aby komponenty były bardziej przydatne do ponownego użycia, wprowadziłem tu i tam Dynamic Components, które ładują poprawny komponent specyficzny dla produktu w zależności od InjectionToken, który określa aktualnie aktywny produkt. Wszystko było ładne i dobre, dopóki nie spróbowałem zrefaktoryzować przepływ kroków, który ma kilka typowych kroków, ale także kilka kroków specyficznych dla produktu. Był to problem, ponieważ przepływ kroków jest nie tylko oparty na komponentach, ale także zależny od tras. Oznacza to, że przepływ krokowy produktu może mieć kilka dodatkowych kroków, tj. trasy, które różnią się od pozostałych. Liczba kroków może się również różnić.

Brudnym obejściem byłoby utworzenie stałej liczby tras o nazwach: step1, step2, step3, a następnie dynamiczne ładowanie komponentu w każdym kroku, ale ponieważ liczba kroków jest różna, nie jest to możliwe. Właściwym rozwiązaniem jest użycie routingu dynamicznego .

Zwykle definiujemy trasy modułu bardzo statycznie w module routingu w ten sposób:

Po załadowaniu modułu nie ma logiki, która mogłaby kolidować ze statycznym przypisaniem tras, więc zawsze będzie trasa domowa i nic więcej.

Przykład

Spójrzmy na bardzo uproszczony przykład, który może nie ma większego sensu, ale ma na celu zademonstrowanie działania routingu dynamicznego:

Chcemy stworzyć aplikację z następującymi trasami:

• Dom (statyczny)
• 404 Nie znaleziono (statyczny)
• Dzień (dynamiczny; dostępny tylko między 6:00 a 18:00)
• Noc (dynamiczna; dostępna tylko między 18:00 a 6:00)
• Sekret (dynamiczny; 50/50 szansa)

Teraz, gdy definiujemy nasze trasy w sekcji providerów, możemy skorzystać z obiektu definicji dostawcy useFactory . W ten sposób możemy przekazać fabrykę zawierającą logikę decydującą o tym, jak powinny wyglądać trasy.

Krótkie przypomnienie: Jeśli załadowałeś moduł o 5:59 i poczekałeś do 6:01, trasa dni nie będzie dostępna, ponieważ konfiguracja trasy została już wcześniej wykonana. Oznacza to, że logika definiująca trasy dzieje się tylko raz, gdy moduł jest ładowany.

Wniosek

Mam nadzieję, że pokażę Ci coś nowego i ciekawego. Jeśli interesuje Cię Angular, sprawdź moje inne posty na blogu na Medium.

Pełny przykład jest dostępny na moim GitHubie: