2 A standalone future

In the previous chapter, we learned about recent developments in Angular and laid out a learning plan for this book. We also created a project and already encountered standalone components. Now it is the time to explore one of the new capabilities of modern Angular, building applications without NgModules, colloquially known as standalones, and understand both the benefits and shortcomings of this approach. To do so, we first need to examine the reasons why teams are making a switch away from NgModules in a more profound way.

2.1 Why abandon NgModules?

As we know, before Angular v14, all Angular applications used NgModules to be able to run. It was the very first Angular concept new developers learned about, and it was the glue that held Angular applications together; components, in contrast, were specifically not that glue. In this context, NgModules were a fundamental part of the framework. So what changed? Why change so drastically? It turns out not everyone was happy with NgModules.

2.1.1 Hard to learn, hard to explain

2.1.2 Indirectness and boilerplate

2.1.3 Other concerns with NgModules

2.2 Previous solutions

2.2.1 Hierarchic shared modules

2.2.2 Enter SCAMs

2.3 Developing apps without NgModules

2.3.1 Creating our first standalone component

2.3.2 Routing standalone components and providing dependencies

2.4 Lazy-loading components

2.4.1 Lazy-loading with NgModules

2.4.2 Lazy-loading a single standalone component

2.4.3 Lazy-loading several standalone components

2.4.4 Providing dependencies only to certain routes

2.4.5 Lazy-loading a component into another component

2.5 Migrations and common pitfalls

2.5.1 Migrating by hand