This tutorial presents a series of articles on building an effective Angular application architecture, based on best practices used at Ekobit.
In the Angular architecture tutorial I you were introduced with an initial structure of an Angular application, together with a process of building and preparing your first Angular application for deployment.
As an Angular project evolves, in this part of the Angular architecture tutorial we would create modules, load them dynamically, share their data and start to build modular architecture.
It’s assumed that you’re familiar with the basics of NuGet packages and the Single-Page Application (SPA) paradigm that’s used to build client-side web applications. It’s also assumed that you’re familiar with TypeScript, and that you have at least some experience in building Angular applications.
Expanding your architecture
For most smaller applications and architectures where the separation of concerns isn’t relevant, having just an application in the src folder is sufficient.
Later on, more projects can be bound together in the same application folder (and source control repository), as the complexity and demands of the project usually only increase.
Modular project architecture in Angular
For creating a new module inside an existing Angular application, you can use the following command:
ng g module <module-name> --routing=tru
This command will create a new module in the folder that carries the module name, as well as an additional module for routing.
The ‘glue’ that connects the modules to one another is the Angular routing. Whenever a call is made to fetch a component or another asset from a module, the call is firstly found and checked by a routing module.
As seen from the screenshot below, the root module – usually called the ‘app.module‘) includes the root routing module – the app-routing.module – which defines navigational routes for accessing the root modules’s content. Each time a client makes a request, these routes will be parsed from top to bottom to find out the correct match. If the request is valid, the client will be navigated to the corresponding content. As in the example below, the root module can define routes from outside the module, and also evaluate paths that are dynamically loaded.
Sharing data between the modules
In order to make the code inside the modules available, a module can be imported into the main (root) module.
In the example above, the devices (‘child’) module is imported into the root module in this way. This is a more direct way to bind modules together because the target module is being compiled along with the main module, and the overall size increases accordingly. This approach can be used when there’s a tight connection between the root and imported modules, as all components and directives will be implicitly available (in the HTML templates, for example).
The most common problem in such application organization is that a child module can’t be imported into some other child module. This is because it’s already been imported into a root module. Because of this, a shared module paradigm can be used.
It’s assumed that a shared module consists of code that’s not tightly coupled with the rest of the application’s structure. In general, it contains directives, pipes, models, services and helper classes used throughout the application, a feature that embodies the DRY (Don’t repeat yourself) principle. Some third-party library providers use this paradigm to categorize their delivered application bundles (also known as ‘barrels‘) by type (components, directives, validators) and functionality set (a dropdown control, a pie chart control, etc).
Sharing data between dynamically loaded modules is somewhat harder because there’s no direct communication between the main module and the loaded module.
There are, however, a couple of ways to circumvent this – easiest of them is through route parameterization.
When navigating to a distant (outside) route with a route parameter, the code inside the target component should read the route parameter from the router and act accordingly.
Alternatively, component attributes – as in any other common case – can be set through the @input variable of the target component. Be careful though: communication through the (singleton) service should be avoided, as there’s no guarantee about the service’s availability and the modus operandi intended from within the target component.
Note: All of the source codes used in these articles are available here.