Transitioning from Component-Based to Module-Based Architecture in Angular: A Personal Journey

In my journey with Angular, I encountered a perplexing issue while using the latest component-based architecture alongside self-created or hosted libraries for common functionalities. These libraries required configuration settings, which were conveniently managed using the forRoot module pattern.

Let me attach a diagram to explain it further:

Let's return to the issue at hand. The Auth library is responsible for handling all authentication-related tasks and displaying any errors that occur. For this purpose, we use a Toast component, which internally injects a message service from PrimeNG.

Since each project requires its own configuration for the Toast component, the responsibility of adding it to the DOM was given to the consumer. The challenge arises because the Auth library needs to push messages into the service's observable, requiring an instance of the message service within the Auth library. However, since the Toast component selector is declared in the app component, it necessitates importing the module, which indirectly injects a new instance of the message service.

As a result, when the Auth library pushes messages into the message service instance, and the app component listens to the observable, they operate on different class instances, causing the messages not to display. To diagnose this, I had to enhance my debugging skills significantly, performing memory profiling of heap snapshots and searching for class names to examine the objects associated with those classes in memory.

Once the issue was identified, we explored possible solutions:

1. We could move the Toast component back to the Auth library and pass additional configurations to render it according to the consumer's needs.

2. We could write a wrapper service over the message service, making it a singleton, and attempt to integrate it with PrimeNG's component. (This approach was not attempted as it would require copying and overriding their implementation.)

3. We could revert to a module-based approach in the main project, as it was effective in other products.

Despite trying multiple approaches, the question lingered: why did it work in one project but not in another? What does the module-based root component have that the standalone root component lacks?

Fortunately, we discovered that when declaring the Toast module for the root component, it must be done in the app.module, along with the Auth library configuration. By loading this module at once, it ensures that the service is created and provided, generating a single instance that is shared between both modules requesting the dependency.