We have reached a point in our journey where we can successfully develop more complex applications by nesting components within other components, in a sort of component tree. However, bundling all our component logic in a unique file is definitely not the way to go. Our application might become unmaintainable very soon and, as we will see later in the chapter, we would be missing the advantages that Angular's dependency management mechanism can bring to the game.
In this chapter, we will see how to build application architectures based on trees of components, and how the new Angular 2 dependency injection mechanism will help us to declare and consume our dependencies across the application with minimum effort and optimal results.
In this chapter, we will cover these topics:
- Best practices for directory structures and naming conventions
- Different approaches to dependency injection
- Injecting dependencies into our custom types
- Overriding global dependencies throughout the component tree
- Interacting with the host component
- Overviewing the directive life cycle
Modern web applications based on web component architectures often conform to a sort of tree hierarchy, wherein the top main component (usually dropped somewhere in the main HTML index file) acts as a global placeholder where child components turn into hosts for other nested child components, and so on and so forth.
There are obvious advantages to this approach. On one hand, reusability does not get compromised and we can reuse components throughout the component tree with little effort. Secondly, the resulting granularity reduces the burden required for envisioning, designing, and maintaining bigger applications. We can simply focus on a single piece of UI and then wrap its functionality around new layers of abstraction until we wrap up a full-blown application from the ground up.
Alternatively, we can approach our web application the other way around, and start from a more generic functionality just to end up breaking down the app into smaller pieces of UI and functionality, which become our web components. The latter has become the most common approach when building component-based architectures. We will stick to it for the rest of the book, undertaking architectures as the one depicted here:
Application bootstrap
└── Application component
├── Component A
├── Component B
│ ├── Component B-I
│ └── Component B-II
├── Component C
└── Component DFor the sake of clarity, this chapter will just borrow the code we wrote in the previous chapters, and we will deconstruct it into a component hierarchy. We will also allocate some room in the resulting application for all the supporting classes and models required to give shape to our pomodoro tool. This will turn into a perfect opportunity to learn the intricacies of the dependency injection machinery baked into Angular 2, as we will see later in this chapter.