Understanding Angular as a Kindergarten

Ever since I started my career as a web developer, I’ve been working mainly as a frontend developer with Angular. One of the things I quickly understood is that the React and Angular communities are waged in a cold war. People who don't know these two technologies might not really understand why this is the case, as they’re both good at what they do.

I’ve seen that, in most cases, React is the most popular choice people make. And when I ask them why, I often hear things like “Angular is too complicated” or “React is way simpler and lighter.”

Fear not, my fellow developers. Today, I’ll introduce to you the power of Angular!

As with every framework or library, we need to know a little bit about them before starting. I know from experience that reading the documentation may be a costly and boring task to undertake, but I’ll try to simplify it.

First of all, everything is typed in Angular. We use TypeScript to help us in this regard. Second, it’s important to know that a generated Angular project always comes with a script that bootstraps a module. Then there’s the module that does all the magic we need. If you aren’t familiar with what a module is just yet, we’ll get there. Third, decorators are very common in Angular and are ultimately what decides if one thing is supposed to work or not. Fourth, Angular is an object-oriented framework (not in a traditional way, but still is). And fifth, every single class has a decorator.

Although it may sound funny at first, Angular can be easily explained if we think about it as a kindergarten.

As a little introduction, let’s think about a kindergarten very superficially. We have the building and a management team, which often is composed of teachers, but let’s assume there are people only responsible for that kind of job. We have teachers, each one of them with a single class to handle. Some of them have slightly different responsibilities like, for example, to teach children with special needs. They might be needed in several classes. There are some cleaning staff, probably a receptionist or two (if it’s a private kindergarten), some cooks, etc. In general, let’s call them non-teaching staff. In this kindergarten, we’ll have some invisible spirits as well that sometimes change things in certain ways and some invisible souls that are helpful. And then we have the kids.

It is a hell of a kindergarten, isn’t it? Spirits, souls, and all… But where does Angular fit in here?

Before we begin comparing Angular and our kindergarten, we must know some names related to Angular that we will use:

– Bootstrapper Module
– Module (NgModule)
– Component
– Service (Injectable)
– Directive
– Pipe

We should consider the bootstrapper module as analogous to the kindergarten’s management team. It’s a class that, ultimately, will have all the required information about the application for it to work properly. As the management board needs to know everything that’s going on inside the kindergarten, so does the bootstrapper module. But make no mistake: neither of them micromanages their components (or, at least, they shouldn’t).

Then, we have some other modules. Modules, in general, are classes that take no logic but, instead, have things registered on them, such as components, services, etc. Modules should be registered inside other modules (or at least directly in the bootstrapper module). The bootstrapper module is a module, as well, but with the responsibility of starting the application. That’s the reason I highlighted it.

Non-bootstrapper modules are the teachers: each one of them has and manages only the information it needs. For example, class 1 does not need the information of class 2 and vice versa. Therefore, each one of them has their own info registered inside.

“But, Pedro… What if we have a module that needs shared info?” you ask. The question is self-explanatory: you create a module in which you register the shared items. After that, you register that module in the other modules. This is similar to a special needs teacher going from room to room as needed. Simple, isn’t it?

Components are to Angular as the kids are to their kindergarten. Each one of them has their own personality, just like components have their own responsibility. They are composed of 3 parts: how they are (HTML), what they look like (CSS), and how they behave (TS). Components are the main part of the application and kids are the most important part of the kindergarten.

You only need modules and components for the application to work, as you need a management team, teachers, and kids for a kindergarten to operate. Yeah, I know that most schools close when there is no staff. My point is that the non-teaching staff can be replaced by teachers. Should they be? Of course not. Neither should services, pipes, or directives.

Services are the staff. They may or may not be allocated to a classroom or teacher, but, once they are called by the teacher(s), there they go, ready to perform! It happens similarly in Angular: you register the service in the module and you can call it in any component of that module for it to be automatically available.

For the sake of this comparison, let’s say a person has 3 parts: a body, mind, and soul. In this example, the directive is the soul. A soul has no form (HTML), has no look (CSS), but has behavior (TS). Like the kids, every soul has its own personality, but every single one of them aims to help. Unlike the kids, they are not whole, because they target a specific thing and always help in the same way. They are not very smart but can be helpful to the whole application, as they enhance its powers. A directive is a simple class that targets a selector and helps its targeted element with something specific, usually to add some behavior to the DOM or to change the way it looks taking into account some information.

Directives are not very often used, as their power is often available in a component, but can be very helpful to normalize the whole application.

Just another quick note: components are directives too, but they are more powerful, as they can interact and think on their own, just like kids.

Pipes can be compared to spirits. Their way of helping is very simple: they take some data, they chew on it somehow and spit it back out. As directives, pipes have no form and no visual component but have a very specific behavior that makes them quite different from directives. Pipes are used to treat data while directives are used to treat the DOM; that’s their main difference.

Just like souls, spirits are not too common, and, similarly, pipes are rarely used.

Hopefully, this analogy gave you a brief idea of how powerful Angular is. I tried to introduce you to how you can easily use each part of Angular for your own benefit. Nevertheless, in order to unleash the whole power of this framework, you should perform additional research about some of the topics I laid out today.

I wish I could talk a lot more about this, but I would be gray and old before I was finished.
I have no doubt that React may be a very powerful library (you guessed it, I’ve never tried React), but I invite you to think twice before saying “Angular is too complicated.” It is better to think that “Angular is too powerful for me to handle.” That I could take! After all, not all of us can be King Arthur and pull Excalibur from the stone!

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –