What is unfortunately often forgotten is that if we want to be able to keep moving fast also one year after we started our project, then we also need to make sure that our project doesn’t become an overconnected ball of mud or to use more technical term, we don’t end up with a tangled dependency graph with lot’s of circular dependencies…

One of the best way to know if this is your case is the constant feeling of being stuck in a spider web when trying to fix one thing leads you to a journey of changing half of the codebase, adding condition after condition just to make it work just this one more time.

Typical example is when we have some feature specific service which manages some kind of feature specific state and then we realize that it would be really great to be able to get that state also in some service in the eager core.

In that case, it’s very easy to just import and inject the feature service in the core service and overlook this eager / lazy boundary violation (or just miss it during the PR review). The outcome will be that the service (and everything else it imports) will suddenly become part of the eager Javascript bundle!

This is bad for performance and for architecture as well as we’re introducing dependencies between parts which should have been isolated (or only depend on each other in one direction, eg feature can consume core, but not the other way around!

Another common offender that tends to happen also in reasonably architected projects is that even though they mostly embraced the eager / lazy split and have most of the logic implemented as the lazy loaded features, for some reason, some of the features are “forgotten”…

The best way to remedy this is to always implement everything including the first (original feature) as a first lazy loaded feature.

Let’s take routing as an example, currently there are at least 4 ways to do it

— eager route to a component with component
— lazy route to a component with `loadComponent`
— lazy route to a module with `loadChildren`
— lazy route to routes based feature (feature-x.routes.ts) with `loadChildren`

In this case, we most likely want to pick one and stick with it.

I would personally recommend to always define lazy route with the routes based feature with loadChildren which is the most modern and flexible way of doing things. Then, in case our lazy feature contains sub navigation, we can lazy load additional components with loadComponent .

The DRY is a principle aimed at reducing the code repetition in the codebase, replacing duplicate code with abstractions.

If the same information or logic is repeated in multiple places, any new requirement which necessitates a change in how it should work will require us to change the logic consistently in all these places which can lead to errors and inconsistencies.

The argument we’re trying to make is that in frontend codebases it’s better to have some amount of duplicated code (e.g. in multiple lazy features) because that will allow them to evolve independently as the requirements change, and they do change!

Madge is a developer tool for generating a visual graph of your module dependencies, finding circular dependencies, and giving you other useful info

— madge npm docs

Using standalone components instead of NgModules means that our dependency graph becomes more granular and this higher resolution allows us to gain better insight of how each parts of app relate to each other and discover more issues!
Besides that, it allows lazy features to cherry pick only those UI components which is actually needs instead of depending on all of them, as was often the case when applications grouped and exposed them in commonly used SharedModule !