(and directives and pipes!)

A few months ago we posted the first RFC related to a project known as “standalone components”. This project has an ambitious goal: to reduce boilerplate and make Angular easier to use and learn by making it possible to build components and applications without NgModules.

This week, we’re building on that foundation with a second RFC discussing how standalone components will be integrated into the rest of the Angular framework. In this post we’ll share a project update, some lessons learned so far and what developers can expect in the near future.

Why standalone components? What’s wrong with NgModules?

Standalone components will:

• Reduce boilerplate in many applications, especially for those already using architectural patterns like the Single Component Angular Module (SCAM) pattern
• Make it easier to learn Angular by removing the NgModule concept from the critical learning journey of developers new to Angular
• Allow us to offer new, more streamlined APIs for common use cases

A common requirement in an application is to lazily load a specific route. Accomplishing this today is fairly verbose. To lazily load a route to LazyPageComponent, for example:

This is a lot of code to write and understand. It’s also too easy to make subtle mistakes. For example, if you forget to import LazyPageModule into LazyPageRoutingModule, this route might fail to work at runtime if LazyPageComponent is missing dependencies.

With new APIs that leverage the guarantees provided by standalone components, the above can be reduced to:

For more details on the proposed loadComponent API for lazy loading individual standalone components, find out more in the new RFC.

What’s in the second RFC?

Over the past few months we’ve focused our efforts on the question of how standalone components fit into the rest of Angular and how they can be used to accomplish specific use cases without needing to fall back on NgModules. The second RFC proposes new APIs that integrate with standalone components to support major use cases that previously required NgModules:

• Bootstrapping an application
• Lazily loading components and/or additional routes via the Router
• Dynamically instantiating components at runtime

Additionally, the RFC covers other APIs related to the larger goal of reducing the need to write NgModules, including:

• Using existing NgModules (such as those from libraries) in the existing APIs
• Providing initialization logic in various contexts, previously supported by NgModules

What challenges have we encountered?

Code size is always a major consideration when adding any new feature to Angular, including the standalone project. We spend a lot of time thinking about the impact new features will have on bundle sizes, and how to minimize that impact in common cases. Often these considerations go both ways: existing applications that still use older APIs shouldn’t need to ship code associated with new ones, but users of newer APIs shouldn’t need to ship code associated with older ones, either.

For example, applications that use the proposed new standalone bootstrapping API shouldn’t need to ship code associated with the previous NgModule-based bootstrapping system. Getting this working optimally is challenging since older APIs have not necessarily been designed with these considerations in mind.

How will this change the Angular style guide?

In the short term we don’t plan on updating the Angular style guide or the default ng new application. Standalone components will be first available as an opt-in feature.

Longer term we’ll be collecting feedback from developers our community as they use the new APIs and will use that feedback to revise both the style guide and the ng new experience.

How far along is the project? When can I use standalone components?

Implementation of the core functionality of standalone components is already well underway, and we’ve begun prototyping the proposed APIs described in the new RFC. As we receive feedback we’ll be refining those implementations.

Since all of the functionality of standalone components and the associated APIs is opt-in and non-breaking, standalone components does not have to wait for a major version — we’ll be able to release this exciting new feature in an upcoming minor version of Angular as soon as it’s ready. So stay tuned as we continue to make progress, and be sure to read through the RFC!