Angular 2.0 — NgModule‘s importance revealed
PREFACE: This post is aimed on Angular 2.0 developers started angular 2.0 before RC 5 or Final version. This post has contents to talk about re-introducing NgModule in Angular 2.0 recent releases and it’s importance is revealed.
Before we really head to the discussion, i’m assuming that someone may wonder why is this discussion required in first point. Since Angular team have released its Final version, that implies Angular 2.0 specification evolution has come to an end. So anything we see as a specification has less possibility to change on a large scale.
On initial releases Angular 2.0 was completely components driven, where we can define a root component and all its bootstrapping falls on the root component. The root component will inherit child components and related child components inherits its own child components. This hierarchy was maintained to achieve Angular 2.0 architecture of making it completely components driven.
What happened later..?
For any application that has larger components (not more number of) and has less number of inheritances involved this architecture was well suited since we handle with less number of inheritances. Even involving more child components using a workaround sufficed the need. But anything that doesn’t follow a standard way of doing will lead to ugly design.
Let’s see previous specification of components handling in meaningful structure.
So if we have to consume other components in our component we’ll have to inject those components in the directives section of your component deceleration. The problem is here, what if this parent components are used by another component and that another component also uses this (parent’s) inherited components.
This will lead to including same components over and over again in all the component deceleration, instead what if something worked as a hub to consume all these components without importing twice. But doing this will change the idea of driving through components, but will start drive through modules (a common hub).
If we start creating module based architecture then the separation logic of creating and consuming a module has to be defined or standardized. This is where the angular module is back to the picture of Angular 2.0 design specification.
A basic module deceleration using the NgModule.
This way of defining a module gives a clear picture on what are the components to be used inside this module and also we have few other clear declarations defining the module. Check this documentation for full all the properties and its usage.
Now what happens to the previous components and how to use the directives inside any component without inheriting.
So how to use this module or what will be best way to use a module driven architecture. Consider when you have multiple business logic speaking to a same back end, but business logic is different from each other.
Now our application is designed in a such a fashion that only modules are defined and these modules are injected on any other module where we can simple create our application flawlessly. Once again modules are a separate entity where we can use its own properties like providers, directives and pipes.
So from the recent specification, Angular 2.0 gives a very promising approach for defining the application by separating modules on our concern and use the components within the module. But how well this will survive or suffice the future requirements, well we’ll have to wait along to identify the real handy nature of Angular 2.0 for web applications.
EPILOGUE: I feel, this entire post is focused based on my understanding on Angular 2.0 and any suggestion or improvisation welcomed.