A quick dive into how things fit together in Angular

A quick dive into how things fit together in Angular

A lot of people tend to complain about how complicated Angular is when compared to React or Vue. This is partly due to misconception, not to mention that React is a library while Angular is a framework — making them very different tools that essentially end up doing the same thing. It’s the conceptual processes that determines your workflow and modes of thinking that are different.

Here’s a quick and simple rundown on how the main parts fits together in Angular, along with a few things I wished someone told me when I was in the beginning of my Angular 2+ journey back in 2016.

Introducing baked in modularity

For those with an object oriented programming background, Angular is a lot friendlier to learn and mentally accept than React or Vue. In part, it is because it was designed to be highly modular and object oriented in approach from the get go.

If you’ve had the chance to work with the original Angular (aka Angular.js), version 1 is more library like in approach than the fully fleshed out framework that we know today. With Angular.js, you could just plop it into any existing application and it would work. Doesn’t that sound familiar?

But as applications grew, things became messy very quickly. Angular.js could be seen as ‘architectureless’ in that you could structure it in any way you wanted. There were style guides but it didn’t guarantee that one Angular.js project would look similar to another in structure and its ability to handle code growth.

Then in 2016, Angular 2 came out and paved the way for the framework that we all know now. Manipulating the DOM and connecting data was no longer the centerpiece as it was with Angular.js. Instead, modularity, re-usability and, OOP paradigms led the way.

Below is a conceptual diagram of what a simple Angular app could look like.

They’re all just classes

Everything in Angular is a class. With TypeScript as its typed superset, Angular is able to turn itself into its own programming ‘language’ while leveraging JavaScript, HTML and CSS as its tech stack.

Decorators are used to help the framework determine how to use the declared class.

Example of @Component() decorator

Decorators declared directly above a class tells Angular what to do with the rest of the code. It is just a function that extends and modifies the code that follows. So in the example above, @Component() declares the class HomeComponent as a component inside the app. In theory, you could rename it not to have the Component part for HomeComponent but the CLI generates this on purpose for convention purposes.

example service with @Injectable() decorator

The above is an @Injectable() decorator that tells Angular that the ensuing class can be imported and used. This is also a reason why services are not registered inside @NgModule and have to be declared and imported in manually.

The main difference between @Component() and @Injectable() is that the first directly tells Angular to use the code with the referenced HTML and execute any binding markups to that particular template. @Injectable() simply extend the logic and processes of your code to your component.

This is also why services are often advocated as a way to separate out your application logic. In theory, your component shouldn’t be fetching data, validating inputs or log to console because that is a service’s job. The concept behind components is that it brings all the modular parts together like a lego board. The component itself is not supposed to participate in the processing or logical parts of your application.

The easiest way to think about components is that it is a space to connect data to HTML. Any transformation of data is to be left to a service. This will ensure true modularity in your Angular application.

So what’s NgModules used for?

Think of @ngModule as the index of everything that’s needed by your web app. When rendering, Angular doesn’t load everything but still need a reference to them when they are needed. This lazy loading methodology allows it to efficiently allocate memory spaces and reduce load times for your app.

It is also used in the build process of your application, where the things declared are what will be included in your final package.

You only need to reference classes and not HTML templates because component decorators have already sorted all that out for you. @ngModule only cares about the things that your app will consume. It gives a thing called compilation context to your Angular app and glues everything together through referencing.

Final Words

At the end of the day, it’s all still just JavaScript. However, Angular extends it by allowing us to use OOP paradigms and makes it easier to enforce SOLID principles while being useful for visual and data manipulation.

Angular was designed to grow and therefore bakes in tried and true methodologies that have been tested in OOP based languages like Java. With React, it’s a free reign kind of experience. Angular, however, requires order and structure due to the lessons learned through the pitfalls of Angular.js.

You could say that JavaScript does have classes and are built on the idea of classes, back in 2016 the functionality just wasn’t in existence yet. TypeScript was employed because of how much it filled in the JavaScript gaps. While JavaScript itself is still playing catch up to the demands and needs of its users, Angular is moving right on ahead and doing what it needs to do.

There is still a lot more to uncover with Angular but I hope that the above diagram and explanations helped unravel one of the major parts that often appear seemingly complicated.

Want to sponsor matcha.fyi? You can have your brand featured right here. Let's connect and chat about it.