Skalowalna i modułowa aplikacja Angular z Nx

Wprowadzenie

Angular to fantastyczny framework, który pomaga podzielić kod aplikacji na różne konteksty. Ale gdy twój kod się rozrasta (a wraz z nim czas potrzebny na zaserwowanie czy zbudowanie aplikacji) , okiełznanie zależności między nimi może stanowić problem.

Korzystając z Nx, możesz przenieść swoją bazę kodu na wyższy poziom; Nx zapewnia  narzędzia do modularyzacji kodu i nakładania ograniczeń architektonicznych (w celu  ułatwienia jego utrzymania, skalowalności itp.). Umożliwia wizualizację modułów za pomocą grafu zależności i wykorzystuje te informacje do poprawy developer experience i  zaoszczędzenia czasu w twojej rutynie. 

Czym jest Nx?

Jeśli otworzysz stronę internetową nx.dev, znajdziesz tę definicję: “Smart, Fast, Extensible Build System“. W skrócie, Nx to potężny CLI, który jest dostarczany z  narzędziami zwiększającymi produktywność programistów, począwszy od uruchamiania  zadań i przyspieszania CI, a skończywszy na generowaniu szablonów kodu. 

Nx powstał w celu ulepszenia Angular CLI, ale obecnie jest framework agnostic;  można go używać z aplikacjami Angular, React, WebComponents i Node, które są obsługiwane przez oficjalny zespół Nx’a, ale można go również używać z innymi technologiami, takimi jak C#, Java, Kotlin. 

Nx można podłączyć do zarządzania wszystkimi tymi technologiami. Istnieją oficjalne  wtyczki lub pakiety (utrzymywane przez zespół Nx’a) oraz pakiety community (utrzymywane przez społeczność). Jeśli chcesz, możesz stworzyć własną wtyczkę od podstaw lub rozszerzyć jedną z istniejących. 

Zanim przejdę dalej, podsumujmy jak Nx może poprawić DX twoich projektów:

• poprzez ograniczenie marnowania czasu na CI i na powtarzalne czynności nad projektem
• zapewnianie zautomatyzowanych aktualizacji, aby narzędzia były zawsze aktualne
• usunięcie nudnych procesów poprzez ich zautomatyzowanie 
• uporządkowanie logiki biznesowej i aplikacyjnej

Jak utworzyć projekt w Nx?

Zajmijmy się praktyką. Aby zainicjować projekt za pomocą Nx, należy użyć prostego polecenia:

> npm create nx-workspace

Możesz użyć npm, yarn lub pnpm. To zależy od ciebie, a wszystkie informacje można znaleźć na oficjalnej stronie internetowej.

Po wpisaniu polecenia i naciśnięciu klawisza Enter skrypt poprosi o podanie pewnych  informacji: 

• Where would you like to create your workspace? angular.love
  Ta nazwa jest używana po pierwsze jako nazwa folderu repozytorium, po drugie jest to npm scope repozytorium
  This name is used first for the name of the folder of your repository, second it is the npm scope of your repository
• Which stack do you want to use? None
  Nx proponuje różne stack’i: None, Angular, React lub Node. Pierwsza opcja to  całkowicie pusty stos, który należy skonfigurować i zainstalować wtyczki; pozostałe są już gotowe do użycia dla wybranej technologii. 
• Package-based or integrated? Integrated
  Technicznie istnieją następujące projekty Nx
  – monorepos (package-based & integrated)
  – standalone (workspace pojedynczego projektu, analogiczny do tego co generuje Angular CLI)
• Enable distributed caching to make your CI faster Yes
  O pamięci podręcznej powiem później, ale ta opcja pozwala usprawnić wykonywanie  różnych skryptów, takich jak budowanie lub testowanie, i zmniejszyć straty czasu  programistów i CI.

Ok, teraz wynik wygląda następująco: 

Jak można zauważyć, struktura projektu jest dość prosta: składają się na nią trzy podstawowe foldery:

• apps: ten folder będzie zawierał wszystkie aplikacje znajdujące się w monorepo (włączając testy e2e). 
• libs: ten folder będzie zawierał wszystkie biblioteki, czyli składowe z których zbudowane będą nasze aplikacje. Podział kodu na biblioteki pomaga podzielić nasz codebase na wiele małych pakietów o określonym scope’ie i dozwolonych zależnościach. 
• tools: ten folder będzie zawierał custom’owe skrypty do automatyzacji procesów.

Przed przejściem do następnego kroku należy skonfigurować repozytorium do  obsługi projektów Angularowych. Aby to zrobić, musisz zainstalować pierwszą wtyczkę w  repozytorium. Wróć więc do terminala i wpisz:

> npm i -D @nx/angular

To polecenie dodaje bibliotekę @nx/angular do zależności dev. Teraz jesteś gotowy, aby  rozpocząć tworzenie swojej pierwszej aplikacji z Nx.

Kod dostępny tutaj 

Stwórz swoją pierwszą aplikację

Nadszedł czas, aby stworzyć swoją pierwszą aplikację Angular za pomocą Nx. Jak  wspomniano wcześniej, Nx to CLI, więc można to zrobić za pomocą polecenia. 

> npx nx generate @nx/angular:application --prefix=ngl

Polecenie to jest interaktywne i należy odpowiedzieć na kilka pytań, które pomogą stworzyć najlepszą konfigurację dla danego przypadku:

• What name would you like to use for the application? E-commerce
• Which stylesheet format would you like to use? scss
• Would you like to configure routing for this application? yes
• Would you like to use Standalone Components? Yes

Myślę, że każde pytanie jest jasne, jeśli znasz Angular, więc nie chcę wchodzić w nie zbyt  głęboko. 

Wynik może cię początkowo zaskoczyć. Zamiast jednej zostały stworzone dwie nowe aplikacje w folderze apps: e-commerce i e-commerce-e2e. Pierwsza to aplikacja angularowa, a druga zaś to projekt Cypress, którego można użyć do testowania e2e aplikacji  e-commerce. W tym artykule nie będę zagłębiał się w testowanie e2e z Cypress, ale jeśli jesteś zainteresowany tym tematem na stronie Cypress lub na stronie Nx, możesz znaleźć wiele wartościowych źródeł na ten temat. 

Ok, teraz nadszedł czas, aby porozmawiać więcej o nowej aplikacji  angularowej. Po pierwsze, można ją uruchomić za pomocą prostego polecenia:

> npx nx serve e-commerce

Teraz w przeglądarce możesz zobaczyć aplikację uruchomioną pod tym adresem:  http://localhost:4200/ i powinieneś zobaczyć ekran powitalny Nx’a.

Teraz możesz wyczyścić projekt z tych zbędnych plików. Przejdź do folderu apps/e-commerce/src/app i usuń pliki nx-welcome.component.ts,  app.component.html, app.component.scss i app.component.spec.ts. Następnie edytuj app.component.ts usuwając komponent NxWelcome.  

Wynik wygląda następująco:

Teraz twoja aplikacja jest pusta i gotowa do developmentu.

Podczas pracy z Nx należy wyobrazić sobie aplikację jako orkiestratora platformy.  Aplikacje powinny jedynie orkiestrować biblioteki, a biblioteki powinny zawierać reguły biznesowe; wiem, że w tym momencie zrozumienie tych dwóch pojęć jest nieco trudne, ale pod koniec tego artykułu docenisz korzyści płynące z tych dwóch podstawowych zasad w Nx i powód, dla którego są one tak ważne. 

Teraz nadszedł czas, aby stworzyć swoją pierwszą bibliotekę w naszym projekcie.
Kod dostępny tutaj 

Stwórz swoją pierwszą bibliotekę

Aby utworzyć bibliotekę, należy uruchomić kolejne polecenie:

> npx nx generate @nx/angular:library pages --buildable --directory=libs/home --inlineStyle --inlineTemplate --prefix=ngl --standalone  

To polecenie jest nieco długie – później pokażę ci, jak uprościć jego tworzenie za pomocą rozszerzenia do IDE o nazwie Nx Console, ale teraz chcę skupić się na wyjaśnieniu, co ono właściwie robi. Rozbijmy je więc na części. 

npx nx wywołuje CLI Nx. Następnie generate wskazuje, że chcesz wygenerować szablon. Używając składni @nx/angular:library,  wskazujesz, że chcesz utworzyć bibliotekę udostępnianą przez moduł @nx/angular. Page to nazwa biblioteki. Directory to katalog, w którym chcesz przechowywać bibliotekę w repozytorium, inlineStyle wskazuje, że chcesz deklarować style bezpośrednio w pliku .ts, i to samo dotyczy inlineTemplate, ale dla html twoich komponentów. Prefix deklaruje prefiks dla komponentów zadeklarowanych wewnątrz biblioteki, a standalone ustawi im tą opcję w dekoratorze komponentu.

Ale teraz chcę porozmawiać o fladze buildable. 

W Nx istnieją trzy typy bibliotek: Workspace, Buildable i Publishable. Biblioteki  Workspace to biblioteki bez skryptu kompilacji. Zasadniczo można je testować lub lintować, ale tego rodzaju biblioteki nie tworzą artefaktów. 

Biblioteki Buildable dodatkowo zawierają polecenie build. Polecenie build umożliwia budowanie tych bibliotek i tworzenie artefaktów biblioteki. Tworzenie artefaktów pozwala Nx’owi poprawić wydajność budowania zarówno w fazie developmentu, jak i na CI. 

Biblioteki Publishable są jak biblioteki Buildable, ale posiadają dodatkowe polecenie publish. To polecenie pozwala opublikować bibliotekę w rejestrze Npm (Npm, GitHub lub gdziekolwiek chcesz). 

Ok, po tym wyjaśnieniu nadszedł czas, aby przyjrzeć się wynikowi polecenia:

Jak można zauważyć, w folderze libs pojawił się nowy podfolder home/pages, który  zawiera nową bibliotekę. Kod wewnątrz jest dość prosty, więc nie chcę się w niego  zagłębiać, ale chcę poświęcić kilka słów plikowi project.json. 

Plik project.json jest ważnym plikiem dla Nx. Przypomina on plik angular.json dla Angular  CLI. Plik ten opisuje wszystkie polecenia włączone dla biblioteki i zawiera konfigurację dla  każdego polecenia. Polecenia znajdują się wewnątrz props’a targets. 

Więcej informacji można znaleźć tutaj. 

Ok, teraz nadszedł czas, aby rozszerzyć naszą aplikację o nowe biblioteki i zobaczyć efekt w przeglądarce. Przejdź więc do apps/e-commerce/src/app/app.routes.ts i dodaj nową trasę:

Następnie uruchom polecenie:

> npx nx serve e-commerce  

A w przeglądarce powinieneś zobaczyć nowy komponent i tekst “home-pages works!”.

Teraz stwórzmy nową bibliotekę dla produktów:

> npx nx generate @nx/angular:library pages --buildable --directory=libs/products --inlineStyle --inlineTemplate --prefix=ngl --standalone  

Podłącz tę nową bibliotekę do aplikacji dodając wygenerowany w niej komponent do routingu: 

apps/e-commerce/src/app/app.routes.ts 

I ponownie uruchom aplikację. Teraz, jeśli przejdziesz do ścieżki /product, powinieneś zobaczyć stronę produktu. 

Przed zamknięciem tego akapitu o bibliotekach, chcę zostawić cię z jeszcze jedną koncepcją dotyczącą bibliotek w Nx. Jeśli chcesz stworzyć skalowalną aplikację z Nx,  musisz podzielić swoją bazę kodu na różne biblioteki różnych typów. Zasadniczo, jeśli pracujesz nad aplikacją frontendową, typy, które dobrze opisują twoje biblioteki, to feature, ui, data-access i utility. Twoim zadaniem jest zidentyfikowanie i podzielenie kodu w tego rodzaju  bibliotekach, aby stworzyć skalowalną i dobrze zorganizowaną bazę kodu. Nie jest to jedyny słuszny sposób podziału projektu, dlatego warto wypracować swój własny, niemniej warto kierować się wzorcami zalecanymi w oficjalnej dokumentacji i iteracyjnie wypracować możliwie najlepszą strukturę.

Kiedy przygotowywałem się do artykułu, jedno z pytań, które otrzymałem, dotyczyło tego, czy jest możliwe podzielić aplikację abstrahując od logiki biznesowej (od dołu do góry). Jednakże, aby stworzyć skalowalną aplikację, musisz znać swój ograniczony kontekst. jego znajomość jest niezbędna, ponieważ tak działa biznes platformy, którą budujesz. Więc nie kierując się logiką biznesową jesteśmy narażeni na stworzenie bazy kodu, która nie opisuje wartości biznesowej i nie poprawnie opisuje zależności między częściami kodu. Zasadniczo kod musi szanować ograniczony kontekst biznesowy; to biznes kieruje bazą kodu, a nie odwrotnie. Baza kodu musi przynosić wartość firmie, więc projektując dobrze zorganizowaną bazę kodu, musisz znać swój biznes i odzwierciedlać go w swojej  architekturze. Tak więc, moim zdaniem, niemożliwe jest podzielenie bazy kodu od dołu do  góry, a znajomość kontekstu biznesowego jest niezbędna do wprowadzenia dobrej architektury aplikacji. Więc sugestia – jeśli architektura twojej aplikacji się nie klei, warto wziąć pod uwagę prawo Conwaya i włożenie wysiłku w poprawę komunikacji w zespole, tak, aby jego członkowie mieli solidną znajomość kontekstu waszej platformy.

Kod dostępny tutaj 

Tagi zapobiegające błędnym zależnościom

Teraz już wiesz, w jaki sposób możesz tworzyć aplikacje i biblioteki, ale tworzenie  niewłaściwych zależności między nimi jest łatwe. 

Istnieją dwa sposoby radzenia sobie z tym problemem; po pierwsze, pozostawienie odpowiedzialności zespołowi; jest to najłatwiejszy sposób, ale w tym przypadku łatwo jest  przeoczyć niewłaściwe zależności, które będą trudne do naprawienia. Drugi sposób, sugerowany  przez zespół Nx, to wykorzystanie tagów w połączeniu z Eslintem. Tagi to proste etykiety ustalone przez zespół w celu identyfikacji dwóch rodzajów rzeczy, funkcji technicznej i kontekstu biznesowego biblioteki lub aplikacji. 

Jeśli chodzi o tagi techniczne, zespół Nx sugeruje użycie pojęć widzianych wcześniej: feature, ui, data-access i utility. Do ich zadeklarowania używamy przedrostka type np.: type:feature, type:ui, type:data-access, type:utility. Istnieją również dwa dodatkowe znaczniki: type:app i type:e2e używane do opisywania aplikacji

i aplikacji e2e, które również powinny podlegać ograniczeniom zależności. 

Następnie istnieje kolejna krytyczna grupa znaczników używanych do opisania wartości biznesowej bibliotek lub aplikacji; znaczniki te używają prefiksu scope, a po nim następuje zakres biblioteki: na przykład: scope:home, scope:products lub scope:shared. Jak można zauważyć, w tym przypadku zespół jest odpowiedzialny za identyfikację zakresów objętych przez aplikacje.

Więcej informacji na temat tagowania można znaleźć tutaj.

Ok, teraz nadszedł czas, aby zrozumieć, jak przekształcić te wszystkie piękne słowa w  realne korzyści dla repozytorium. 

Najpierw otwórz plik .eslintrc.json w katalogu głównym projektu. Plik ten zawiera reguły dla  repozytorium. Domyślnie Nx jest skonfigurowany tak, aby akceptować każdą zależność między modułem; jest to zadeklarowane przez poniższy fragment:

Aby wskazać Nx nasze ograniczenia zależności, należy zmienić tablicę depConstraints i  dodać swoje reguły. 

Na potrzeby tego artykułu zadeklarowałem takie przykładowe reguły:

W przypadku konfiguracji technicznej (zdefiniowanej za pomocą prefixu type) jest to uniwersalna konfiguracja dla różnych projektów. Jeśli chodzi o scope, musi on odzwierciedlać konkretną logikę biznesową i dla każdej platformy musi być zdefiniowany indywidualnie. 

Ok, zdefiniowałeś swoje ograniczenia, ale teraz musisz użyć odpowiednich tagów w swoich bibliotekach i aplikacjach. Można to zrobić na dwa sposoby: dodać tagi w pliku package.json lub w pliku project.json każdego z modułów. 

Na potrzeby tego artykułu dodałem tagi w pliku project.json; oto przykład: 

Resztę konfiguracji można znaleźć tutaj. 

Teraz, aby pokazać prawdziwy scenariusz, chcę dodać kolejną bibliotekę do aplikacji za  pomocą następującego polecenia:

> npx nx generate @nx/angular:library ui --buildable --directory=products --inlineStyle --inlineTemplate --prefix=ngl --standalone --style=scss --tags=type:ui,scope:products

Jak można zauważyć, ta biblioteka jest biblioteką interfejsu użytkownika dla produktów. Na przykład, jeśli spróbujesz użyć komponentu wewnątrz tej biblioteki w bibliotece home/pages, dostaniesz błąd:

libs/home/pages/src/lib/home-pages/home-pages.component.ts 

Jeśli masz już skonfigurowany VsCode i rozszerzenie EsLint, możesz zauważyć, że rozszerzenie wyświetla błąd, a komunikat mówi, że projekt z “scope:home” może zależeć tylko od bibliotek oznaczonych jako “scope:shared” i “scope:home”. 

Jeśli nie masz rozszerzenia, możesz uruchomić następujące polecenie:

> npx nx run-many --target=lint

Wynik jest taki sam: 

Jak można sobie wyobrazić, dobrze zdefiniowana konfiguracja może zapobiec dziwnym zależnościom w projektach. 

Jeśli usuniesz ProductsUiComponent z home i przeniesiesz go do komponentu strony  produktów, zauważysz, że problem zniknie i wszystko będzie działać poprawnie. 

Kod dostępny tutaj 

Szybkie polecenia dzięki pamięci podręcznej

Jak można zauważyć, Nx pozwala na korzystanie z różnych poleceń i prawdopodobnie  pomyślisz, że wszystkie te polecenia mogą zmniejszyć twoją produktywność podczas  codziennej rutyny; będziesz czekać dużo czasu, aż się skończą, i będziesz robić dużo przerw na kawę. 

Ale Nx ma w zanadrzu jeszcze jedną świetną funkcję. Nx może cachować wyniki poleceń i ponownie je wykorzystywać w przyszłości, aby zwiększyć produktywność i Dx. Jeśli otworzysz plik nx.json w katalogu głównym projektu, możesz zauważyć właściwość wyjaśniającą.

Ta właściwość wskazuje Nx, które polecenia muszą być cachowane. 

Aby pokazać, jak to działa, można uruchomić następujące polecenie: 

> npx nx run-many --target=build --skip-nx-cache
lub
> npx nx run-many -t build --skip-nx-cache

Prawdopodobnie będziesz musiał poczekać cztery lub pięć sekund, zanim skrypt zostanie  ukończony; dzieje się tak, ponieważ skrypt nie korzysta z pamięci podręcznej Jeśli spróbujesz wykonać polecenie bez opcji –skip-nx-cache:

> npx nx run-many --target=build

Prawdopodobnie tym razem skrypt zakończy się w ciągu kilku milisekund; jeśli nie, uruchom  go ponownie, a skrypt zakończy się w ciągu kilku milisekund. To samo dotyczy poleceń test, lint  i e2e. 

Nx buforuje artefakty w oparciu o pewne parametry, takie jak wersja pakietów w pliku  package.json, hash pliku i kilka innych rzeczy. A jeśli na przykład zmienisz plik i ponownie  uruchomisz skrypt, Nx ponownie uruchomi skrypt tylko dla kodu dotkniętego zmianami. Na przykład, jeśli zmienię tekst komponentu w sekcji:

libs/home/pages/src/lib/home-pages/home-pages.component.ts i uruchamiam skrypt  kompilacji: 

> npx nx run-many --target=build  

W konsoli zobserwujemy:

✔  nx run products-ui:build:production  [existing outputs match the cache, left as is]

✔  nx run products-pages:build:production  [existing outputs match the cache, left as is]

✔  nx run home-pages:build:production (1s)

✔  nx run e-commerce:build:production (2s)

Jak można zauważyć, polecenie kompilacji przebudowało tylko stronę główną i moduł e-commerce; ponieważ zmiany nie mają wpływu na moduł produktów, a Nx może ponownie wykorzystać istniejące artefakty, ten moduł nie zostanie przebudowany. 

Jest to doskonała funkcja, która może usprawnić twoją rutynę, a być może także CI. Tak, powiedziałem CI, ponieważ Nx oferuje produkt o nazwie Nx Cloud, który umożliwia udostępnianie artefaktów między różnymi urządzeniami. Jeśli więc jeden członek zespołu już zbudował tą wersję modułu to będzie ona scachowana przez Nx Cloud, a CI zajmie mniej czasu na wykonanie swoich zadań. Nx Cloud jest płatne do użytku komercyjnego (wszystkie szczegóły można znaleźć tutaj), ale jeśli masz projekt open-source lub osobisty, możesz go używać za darmo bez żadnych problemów. 

Nx Console do ulepszania DX w VsCode i WebStorm

W tym momencie myślę, że boli cię głowa od tych wszystkich nowych informacji i  prawdopodobnie zastanawiasz się, jak możesz zapamiętać te wszystkie skomplikowane polecenia dostarczane przez Nx’a. Jednak jest na to proste rozwiązanie. Zespół Nx stworzył doskonałe rozszerzenia o nazwie NxConsole, zarówno dla VsCode jak i dla WebStorm, które pozwalają na interakcję z CLI poprzez prosty graficzny interfejs użytkownika. Ten interfejs użytkownika umożliwia uruchamianie poleceń, takich jak budowanie, testowanie, czy lintowanie, tworzenie nowych aplikacji lub bibliotek; uruchamianie pojedynczego polecenia w określonym projekcie i wiele innych użytecznych narzędzi, które poprawiają DX w rutynowej pracy.

Poniżej umieszczam screen z menu:

Korzystając z tego prostego interfejsu użytkownika, nie musisz pamiętać o wszystkich poleceniach, wystarczy wiedzieć co chcesz zrobić i kliknąć odpowiednią opcję a rozszrozszerzenie uruchomi polecenie za Ciebie. Jeśli zaś polecenie wymaga określenia dodatkowych parametrów, rozszerzenie otworzy nową kartę w edytorze, gdzie będziesz mógł wskazać parametry polecenia w formularzu. Podczas zmiany parametrów rozszerzenie na bieżąco będzie pokazywało jakie pliki zostaną wygenerowane i zmienione (wykorzystując opcję –dry-run), abyś miał pewność, że efekt będzie zgodny z oczekiwaniem. Gdy już ustaliłeś wszystkie parametry wystarczy nacisnąć przycisk run, aby uruchomić wykonanie. 

Moim zdaniem to rozszerzenie jest naprawdę pomocne i znacznie ulepsza DX. Musisz tylko wiedzieć, co chcesz zrobić, a rozszerzenie przeprowadzi Cię po ścieżce do osiągnięcia rezultatu. 

Wizualizacja projektu za pomocą Project Graph

Zanim zakończę ten artykuł, chciałbym pozostawić cię z ostatnim spostrzeżeniem na temat Nx. Moim zdaniem najważniejszą funkcją tego narzędzia jest Project Graph. 

Korzystając z Nx, można tworzyć wiele małych bibliotek i aplikacji których użycie będzie tworzyło zależności między nimi. Posiadanie wizualizacji tych zależności jest pomocne aby zrozumieć te zależności.

Project Graph to aplikacja internetowa, którą można uruchomić na dwa sposoby: przez CLI za pośrednictwem terminala lub przez rozszerzenie Nx Console. 

Do tego celu może lepiej sprawdza się polecenie CLI, więc wróć do terminala i uruchom  następujące polecenie:

> npx nx affected:graph

Rezultatem jest nowa karta w przeglądarce, która wygląda następująco: 

Jeśli nie widzisz wszystkich projektów, kliknij przycisk “Show all projects” po lewej  stronie. 

Jak zauważyłeś, strona pokazuje wszystkie moduły w twoim repo i możesz zobaczyć, jak  moduły są ze sobą powiązane. 

Po kliknięciu strzałki relacji można również zobaczyć, który plik tworzy relację oraz czy relacja jest dynamiczna (istniejąca dopiero w runtime’ie, np. lazy loaded route) czy statyczna.

Project Graph udostępnia również inny ważny widok; za jego pośrednictwem można zobaczyć zakres wprowadzonych zmian. Jeśli zmienisz komponent w pliku angular.love/libs/products/ui/src/lib/products-ui/products-ui.component.ts, dodając na  przykład nowy tekst, i uruchomisz to polecenie:

> npx nx affected:graph

Tym razem wynik jest nieco inny: 

Jak można zauważyć, tym razem graf pokazuje moduły dotknięte zmianami w innym  kolorze. Pomaga to zrozumieć wpływ zmian – tzn. na które z modułów mogą one wpłynąć. 

Całe narzędzie Project Graph jest bardzo przydatne. Pozwala zespołowi wiedzieć, jak rośnie repozytorium i umożliwia programistom zrozumienie wpływu nowej funkcji lub poprawki. Zaś świadomość Nx’a co zostało zmienione umożliwia wykorzystanie wspomnianego wcześniej mechanizmu cachowania.

Wnioski

Nadszedł czas, aby zakończyć ten artykuł. Dowiedziałeś się, czym jest Nx i jak utworzyć projekt. Stworzyłeś aplikację za pomocą Nx CLI i odkryłeś korzyści płynące z dzielenia aplikacji na biblioteki. Wiesz, jakie rodzaje bibliotek istnieją w Nx i jak możesz zapobiec niewłaściwym relacjom między bibliotekami o różnych scope’ach. Mam nadzieję, że zrozumiałeś, jak ważne jest używanie bibliotek do tworzenia małych modułów, które umożliwiają tworzenie skalowalnych aplikacji za pomocą Nx. 

Cachowanie zadań nie ma teraz dla ciebie tajemnic i mam nadzieję, że poprawi twoją produktywność w przyszłości. 

Nx Console pomaga poprawić DX i pozwala zapomnieć o wszystkich dostępnych opcjach poleceń, przeprowadzając Cię przez ich konstruowanie. 

Wreszcie, Project Graph wizualizuje stan repozytorium i może pokazać wszystkie relacje i wpływ zmian podczas developmentu. 

Wiem, że Nx może wydawać się trudny do nauczenia się i zrozumienia, ale w rzeczywistości jest to proste; po odkryciu tych podstawowych pojęć opisanych w tym artykule i po pewnym czasu używania go w praktyce, pokochasz go i będziesz miał pojęcie o tworzeniu skalowalnych aplikacji Angularowych i nie tylko. 

W tym artykule opowiedziałem tylko o Monorepo, ale w ostatnim okresie zespół Nx pracował nad nowym sposobem pracy z Nx, tj. ze standalone projektem (nie mylić ze standalone components). Ta konfiguracja pozwala mieć wszystkie zalety Nx w repozytorium z tylko jedną aplikacją. Więcej informacji można znaleźć tutaj. Mam nadzieję, że podobał ci się ten artykuł, a jeśli chcesz zagłębić się w Nx, dokumentacja Nx’a i ich kanał na Youtube zawierają wiele materiałów do nauki.

Dzięki za przeczytanie 🙂 

Kod do tego artykułu jest dostępny tutaj