Mentionsy Mentionsy
Subiektywny Frontend
Subiektywny Frontend

Odwróć zależności albo zgiń – Nx graph day!

19.11.2025 ·15 min 14 s

Odcinek opublikowany 04.09.2025💪 Frontendowa Siłka wraca z mocnym treningiem z odwracania zależności w Nx monorepo! Tym razem trenujemy z NX Graphem, łamiemy zasady module boundaries… żeby je potem przywrócić na nowych, lepszych zasadach.Wprowadzamy nowy token i refaktoryzujemy zależności tak, żeby była moc, a kod był bardziej elastyczny i gotowy na skalowanie – bez spaghetti z importów.📌 Co znajdziesz w tym odcinku?🧩 Praktyczne użycie NX Graph do analizy zależności🚫 Import z zablokowanej biblioteki – jak i dlaczego🔁 Wzorzec odwracania zależności w praktyce (Dependency Inversion)🧼 Czysta architektura = łatwiejsze utrzymanie kodu💬 Daj znać w komentarzu, czy stosujesz odwracanie zależności w swoim monorepo!I pamiętaj – subskrybuj, żeby nie przegapić kolejnych treningów 💥

Zrobimy dalej naszą angularową aplikację. Mamy mikrofrontendy, shelle, tokeny, dependency injection, grafy, wszystko. Wow. Będzie wszystko. Bardzo, bardzo dobrze. Dobra, dobra. Więc tak, mamy aplikację, mamy tą naszą nxowe repo, mamy tutaj shell'a i dwa jakieś tam mikrofrontendy. I ten shell ma też jakąś tam bibliotekę, shell config. A to, co dzisiaj zrobimy, to dodamy nową bibliotekę. I ta nowa biblioteka będzie... Czym? Nie wiem, choć się domyślam. UI. UI, tak. Zrobimy dzisiaj UI-ową bibliotekę. No i dobre.

Czyli mogę sobie wejść do naszego UIA. Ciach, ciach, ciach. Tutaj mamy jakiś UI i możemy sobie Read Only. Ciach, it's MFI Active. Zaimportować. Nie zaimportował, ale zaraz zaimportuje. Subiektywny shell config. Pięknie. Wyświetlimy go? Koniecznie. Jak sprawdzimy, że działa. To bardzo ważne. mfi-active. Dobra. Czyli co my tutaj zrobiliśmy? Dodaliśmy zależność między libui a naszym shell-configiem. No bo wiemy, że shell-config będzie przechowywał tą informację.

No ale on mi tutaj coś podkreśla. Krzyczy. A project without tags matching at least one constraint. Brakuje nam tagów, panie kolego, konfiguracji libki. Dobra. I co ja mam tu dodać? No trzeba sprawdzić. Jeszcze trochę minęło od ostatniego odcinka. Tak, tak, tak. Wchodzimy do naszej konfiguracji. Czyli mamy source tag shell i remote. Hmm, a to nie jest Ani Shell, ani Remote. Czyli musimy dodać prawdopodobnie nowy tag. No dobra, to zrobimy kopię i wklej. I co? Jedziemy shared.

Może być shared. I załóżmy, że Shared może zależeć tylko od Shared. Shared może zależeć tylko od Shared, tak. Ale Remote i Shell może zależeć od Shared, prawda? Tak. Mmm. Dalej go sprzeciwali. Krzyczę? No. Project Vivo to Axe. A gdzie dodałeś ten tag? Nie dodałem. Ma rację, że krzyczy. Wszystko się zgadza. Wszystko się zgadza. A project tagged with shared canonical... No, no, no. To chyba ma sens, co on mówi. No dobra, to może byśmy to w takim razie pokazali na graphie. Wskaza się.

Mamy nasz graph. Pokaż nam wszystko. Nie ma tego dużo. Czyli mamy nasz UI, który zależy od shell configa. I ta dependencja tutaj jest właśnie niedozwolona. Bo tak skonfigurowaliśmy module bandwidth, no i tak generalnie sobie modelujemy ten projekt. Nie chcemy mieć zależności w UI. To ja mam pomysł. To ja zrobię tak, ciach. Konfiguracji. Modelowanie modelewaniem, ale ja zrobię tak. I co ty na to? Odwróć zależności albo zgiń Nx graph day!.

Nasz shared, który jest używany przez wszystkich, raczej nie powinien zależeć od shella, który jest dedykowany aplikacjom i który raczej jest najwyższą warstwą w naszej architekturze. Stąd powinniśmy unikać zależności w przeciwnym kierunku. Czyli no go. No dobra. I tutaj wjeżdża całe nabiało. Odwrócenie zależności. Dokładnie tak. No dobra, no to w takim razie o co chodzi z tym odwracaniem zależności? Mamy nasz graf i żeby odwrócić zależność trzeba zrobić tak, żeby tego tutaj nie było. Prosta sprawa. No. No to bierz ołówki, lecimy. Dobra, to mów. Co robimy w takim razie? Mamy nasz UI.

W sumie możemy nawet active-status sobie zmienić, bo tutaj dodaliśmy w międzyczasie booleana, ale może to być np. string, a może to być jakaś unia. Nie kombinujmy. Chodzi mi o to, że ten token niekoniecznie musi mieć tą samą wartość i ten sam typ, co to, co chcemy tu podać. No bo mamy niezależność. Dlatego mamy tutaj pewną dowolność i kreujemy ten token tak, żeby on był konkretnie dla tego use case'u. Tak. Czyli teraz mamy czystą sytuację. Nasza biblioteka nie ma zależności do shell config, czyli do innej biblioteki. Możemy zerknąć na grafa. Czyli nie mamy żadnego użycia, więc może żeby to było spójne dodajmy to użycie gdzieś w szalu.

Mamy już import, więc uruchamiamy naszą aplikację. OK. Sprawdźmy to. I krzyczy mi tutaj coś. No krzycz, no przecież używamy tokena, który nie jest zaprowajdowany. Czyli wcześniej, jak mieliśmy tę wartość dostępną z shell.config, teraz musimy ją w jakiś sposób zaprowajdować. No po prostu gdzieś. A to gdzieś to przeważnie jest najwyższa warstwa. W naszym wypadku to będzie shell. Więc musimy ustawić tą flagę na poziomie Shellu, tak żeby nasz komponent dalej był funkcjonalny.

Czyli wchodzimy do app.config i provide'ujemy nasz token. Provide MFI active status. I co my tutaj możemy użyć? Możemy użyć w zasadzie wartości statycznej, use value. I możemy zwrócić true. Napisujemy. Wchodzimy do aplikacji, proszę bardzo, status mfi-active true. Świetnie. To nie jest do końca prawda, no bo chcieliśmy ten status brać z naszego shell configa, czyli ten token is mfi-active, no po prostu jakaś tam funkcja. Więc wchodzimy tutaj i możemy na przykład użyć useFactory.

Czy to musi być faktory, czy value? Nie ma znaczenia. Czyli is MFiActive, ciach, ciach, ciach. Czyli wywołujemy tutaj naszą metodę z shell.config. Prowadzimy token true. Odwróć zależności albo zgiń Nx graph day!. Odwróć zależności albo zgiń Nx graph day!.

Pokazano wszystkie 10 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.