In the previous chapters and sections in this chapter, we have seen different approaches and good practices for laying out Angular applications. These guidelines encompassed from naming conventions to pointers about how to organize files and folders. From this point onwards, we are going to put all this knowledge to practice by refactoring all the different interfaces, components, directives, pipes, and services in an actual Angular architecture, conforming to the most commonly agreed community conventions.

By the end of this chapter, we will have a final application layout that wraps everything we have seen so far in the following site architecture:

app/
 assets/ // global CSS or image files are stored here
 core/
  (application wide services end up here)
  core.module.ts
 shared/
   shared.module.ts // Angular module for shared context
 timer/
 ( timer-related components and directives )
   timer.module.ts // Angular module for timer context
 tasks/
 ( task-related components and directive )
   task.module.ts // Angular module for task context
 app
   app.component.ts
   app.module.ts // Angular module for app context
 main.ts // here we bootstrap the application
 index.html
 package.json
 tsconfig.json
 typings.json
 

It is easy to understand the whole rationale of the project. Now, we will put together an application that features two main contexts: a timer feature and tasks listing feature. Each feature can encompass a different range of components, pipes, directives, or services. The inner implementation of each feature is opaque to the other features or contexts. Each feature context exposes an Angular module that exports the pieces of functionality (that is, the component, one or many) that each context delivers to the upper-level context or application. All the other pieces of functionality (inner directives and components) are concealed from the rest of the application.

It is fair to say that it is difficult to draw a line in the sand differentiating what belongs to a specific context or another. Sometimes, we build pieces of functionality, such as certain directives or pipes, which can be reused throughout the application. So, locking them down to a specific context does not make much sense. For those cases, we do have the shared context, where we store any code unit that is meant to be reusable at an application level, apart from media files such as style sheets or bitmap images that are component-agnostic.

The main app.component.ts file contains and exports the application root component, which declares and registers in its own injector the dependencies required by its child components. As you know already, all Angular applications must have at least one root module and one root component, initialized by the bootstrapModule() function. This operation is actually performed in the main.ts file, which is fired by the index.html file.

Defining a component or a group of related components within a context like this improves reusability and encapsulation. The only component that is tightly coupled with the application is the top root component, whose functionality is usually pretty limited and entails basically rendering the other child components in its template view or acting as a router component, as we will see in further chapters.

The last bit of the puzzle is the JSON files that contain the TypeScript compiler, typings, and npm configuration. Since versioning on the Angular framework keeps evolving, we will not look at the actual content of these files here. You are supposed to know their purpose, but some specifics such as the peer dependency versions change quite often, so you'd better refer to the book's GitHub repository for the latest up-to-date version of each one. The package.json file requires a special mention though. There are a few common industry conventions and popular seed projects, like the one provided by the Angular official site itself. We have provided several npm commands to ease the overall installation process and the development endeavor.