6 Concepts to Master to be an Angular Architect

Six concepts every Angular developer should explore in-depth in order to master Angular and design well-architected applications.

Angular is one of the biggest frameworks around: it provides a lot of features out-of-the-box, which means there are quite a few concepts to be able to master if from top to bottom.

There are six specific concepts I think every Angular developer should explore in-depth in order to master Angular and be able to be proficient with writing well-architected applications.

No, knowing its source code is not what’s I think it’s required — although I’ve personally had to explore in a small number of situations.

An Architecture for Cloud Component Hubs

Cloud component hubs like Bit.dev are commonly used to publish, document and organize Angular components. We use them to maximize code reuse and build apps that scale.

As you’ll see in this post, a good Angular architecture ensures our codebase is built in a way that enables easy sharing and reusing components in and across repositories.

Exploring components published on Bit.dev

1) Module/Library Architecture

Angular’s Module architecture is a bit unique, and probably one of the hardest parts to fully grasp for beginners.

The most confusing concept about it is that we’re already using a module architecture on top of it: of course, I’m talking about ES imports.

Because Angular Modules add an additional layer of logical grouping, it’s important to keep them as much related as possible.

But knowing how to separate and split your app’s functionality in well-defined modules is a fundamental part of architecting Angular apps.

Different Types of Angular Modules

There are different types of Angular Modules you should be aware of:

• Declarations/Widget Module (example: a module that is a collection of UI Components, Directives and Pipes)
• Services Module (example: HttpClientModule)
• Routing Module
• Domain/Feature Module
• Core/Shared Module

I wrote in details about each type in the article below:

Library or Module?

I would argue that we can bring this distinction at the library-level : a library with only services, a library that represents a route, and so on.

But whether you’re writing a module or a library depends a lot on your project type, and whether you are using a monorepo or a multi-repo project

Questions to ask yourself before writing a module

Before writing a module, there are a few questions to ask yourself:

• What sort of module am I writing? If you can’t answer this question, you should familiarize yourself with the different types of modules I listed above.
  It’s highly likely you’ll need one or two types of modules, so the answer may very well be two modules: Routing and Service
• Should this module be its own library or should it be simply a module? This is a little bit harder to answer: if you’re using a monorepo, my opinion is that building libraries would be a better option in the long run

2) Separation of Concerns between Components, Services, and Directives

Separating concerns is simple in theory, and yet harder than it seems. We’ve been taught since the Angular.js days to keep components “lean” and services “fat”, and fundamentally there hasn’t been a substantial difference in the newest versions.

It is still important to understand what exactly belongs into Components and what belongs into Services , and why Directives may just be an incredibly underrated feature.

State

Placing state is a matter of understanding whether the data is accessed and shared outside of a component or whether it is local and encapsulated.

• If the state is shared between components, or it needs to be accessed from services, then place your state in a service . It doesn't really matter what State Management tool you use in this case as long as it is in a service
• If the state is local (ex. a form) and only used within a component, then simply store it in a component

DOM Manipulation

Most DOM Manipulation should probably happen within Directives. Let’s assume you’re adding a Drag and Drop functionality to one of your components.

Sure, you can create a component and bind events from there, but at that point, you’re mixing two things:

• how the component looks
• how a certain component’s feature behaves

Directives are the ultimate reusability feature in Angular and I see them underused in almost every project I have worked on. Directives can be used to take off lots of responsibility from Components.