This tutorial is part of the Angular Architectural Patterns series.
In Part 3 of this tutorial, we created two feature libraries with routed components and hooked them up to the check-in feature shell library. We used the generate project tool to create the mobile check-in application and created a mobile-specific template for the flight search component.
In this part, we're going to create two workspace libraries in the check-in domain, the check-in data access library and the check-in feature shell library. We register data access in the feature shell library, create the check-in desktop application and hook up the feature shell Angular module. After reviewing and verifying how much of this is automated by our generate project tool, we quickly generate the mobile check-in application.
Check-in data access library
Let's move on to the check-in domain. This time, we'll start with the data access library. I added an extra option called --with-state to generate a feature store and effects in the +state folder.
This generates the following file and folder structure.
How sweet is this? One command and we've got a project-specific data access library set up with project configuration, path mappings, feature store, and feature effects.
Lint and test the project. Correct any errors like you did earlier.
Check-in feature shell library
We use the generate project tool to generate the check-in feature shell.
Everything's now set up for us.
Let's take a quick look at the check-in feature shell Angular module.
We need to register the shared data access and check-in data access Angular modules.
Great! Since we don't have any features to add to the check-in application yet, we can move on to the next project for now.
Check-in desktop application
It's time to create the first check-in application, the desktop web app. I've added support for feature shells in the generate project tool. If a feature shell library exists in the same scope, the application will be generated with the same changes as we made earlier in this article. We just need to make sure to use the --npm-scope parameter.
Let's make sure it worked. Open up the app module of the new application project.
The app component is generated with the same template as our other apps.
As seen in the app module, we eagerly load the check-in feature shell module which routes to its shell component as we saw in the previous section.
The changes to the app component are reflected in its test suite.
Our Angular testing module adds the router module to make us able to render the app component's template. The heading selector and content now reflects the simple template.
The final change that we want to check is the usage of the shared environments workspace library in the main file.
The generate project tool detects a shared environments library, changes the import statement in the main file and additionally delete the src/environments folder and files which are usually generated as part of an application project.
Now, let's make sure that we're using the shared environments library in the fileReplacements option of our application project's configuration.
We're looking good!
Lint checks and the unit test suite run as expected.
Let's verify the changes to the end-to-end test suites.
For some reason, Angular only leaves out the last name of the project-name for the root element. In this case, event though the application project's name is check-in-desktop, the root element name is check-in-root. The generate project tool respects this.
In the booking apps, the root element name is booking-root rather than booking-desktop-root and booking-mobile-root. This can also be seen in the index.html file of an application project generated using the Angular CLI.
The end-to-end test suite is linted and tested successfully.
Finally, start the application and verify that it renders the title. As no feature libraries have been added yet, only the title is shown, but no errors are thrown.
Mobile check-in application
The final application project is the mobile check-in web app.
The project is generated exactly as described in the previous section.
Let's review the file and folder structure that is generated for us.
With both check-in applications in place, we have the following project folder structure.
Conclusion
Start the mobile check-in application by running the ng run check-in-mobile:serve command.
At this point, our workspace folder structure looks like the following figure.
In this part of the tutorial, we used our generate project tool to generate the check-in data access library. This time, we added the --with-state parameter to automate the generation of feature state that we generate manually in Part 2.
Next, we generated the check-in feature shell library project and hooked up shared data access as well as check-in data access by importing their Angular modules in the check-in feature shell Angular module.
With data access in place, we generated the check-in desktop application and end-to-end test projects. We went through the steps that the generate project tool does for us. Changes we did manually in Parts 1 and 2.
Finally, we generated the mobile check-in application and end-to-end test projects.
We'll finish the monorepo in Part 5 where we create the seatmap domain and the shared buttons UI library as well as the shared formatting utilities library. We'll wrap up the tutorial series by looking at what other features Nx offers us that Angular CLI doesn't provide out-of-the-box.
Top comments (0)