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
Root module
  Root component that is Application component
  Component A
  Component B
  Component B-I
  Component B-II
  Component C
  Component D
Feature module
  Component E
  Component F
Common module
  Component G
  Component H

For 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, as we will see later in this chapter.