Why I Always use Angular
It’s no secret, at this point, that I’m a fan of the Angular framework. I’ve made a lot of comparisons with React, but today I want to do something a little different. This article will be focused on the things I love about Angular and why I use it for all my projects.
The CLI makes my life easier
The CLI makes your life so much easier. It really does. It handles the creation of your app, it handles creating components, upgrading NPM package versions, and with Angular Schematics handles setting up new libraries as well. If you wanted a PWA, all you’d have to do is run one command.
BAM! That one command will configure your app (at any point in development, so if you’ve got a half-made app, this will work the same as a new app) to be a fully-fledged PWA. Angular will also give you super easy-to-use tools to manage your PWA. How about adding SSR (Server Side Rendering)?
DONE! Now you have a fully configured app with SSR. One command, and you don’t have to do any configuration. That’s not to say you can’t update the configuration if you want to. The CLI takes away almost all of the annoying parts of software development, which is the monotonous configuration. This allows me to focus on my app rather than configuring it.
All the Tools for the Job
Angular has all the tools I need for any job. Angular is a framework, which means it comes with a whole bunch of useful stuff. For example, I’ve never had to worry about the third party form handling library not doing something I wanted, being out of date, or not working with my specific use case. Nope, Angular forms are incredibly robust and cover every use case you can throw at them.
Let’s have a look at how we can start using forms in a fresh Angular app. The first step is to import the Forms Module and Reactive Forms Module into the module you want to use forms in.
The next step is actually to use that in our component to construct a form. I will use an example from some code I did when talking about web components.
This gives us a basic contact form, which I feel is something we see on a great many websites. Angular gives us everything we need right out of the box in order to construct a full form with any kind of validation we could possibly want. If we wanted to write custom validators, they are just simple functions.
In the submit method, we can also see that we have plenty of ways of validating data in the form. Let’s see how these fields are used in the view.
As a quick note, this is using Angular Material, which is what the mat- components are.
Angular gives us several ways to interact with the component that runs the form behind the scenes when we create the form. In the form tag, we can tell it what form group we want to use and give it a submit method we want to run when a button is clicked. If you notice, the button at the bottom has no method attached to it. Any button inside a form will automatically trigger a submit method. If you didn’t want a button to trigger that submit method then you can add type=button to it.
We can also see that when we have a form control, like an input, we give it a name that coincides with the name of one of the controls inside the form group. We can also check the validation status of individual fields easily to display any potential errors, like if someone enters an invalid email address.
The Golden Standard
There is a side effect of using the CLI. Angular apps are going to be largely similar in architecture. Angular apps are always going to be made the same; the components will be made the same way, they will always use a service for making HTTP calls, etc. This makes Angular apps predictable and easy to maintain. It also means you do a lot less guessing about how other Angular apps are made. You can come into any Angular app fresh and get straight to work. Have you ever written a bunch of code and then dropped it for a while, and then you come back and wonder who the hell wrote that code (hint: it was you, it was always you). Never happens to me when I’m using Angular.
If we think back to the forms, we can see how those standards will apply to every form in our application. Not only in our application, but every Angular application will handle forms like that.
Like Building with Legos
Much like Legos, Angular is made of building blocks called modules. Modules can encapsulate as much or as little functionality as you want. Make your building blocks however you want. Then you can simply organize your building blocks to fit whatever purpose they need to. If they need to fit a different purpose, you can rearrange them easily.
Again, if we think back to the forms, we had to do some stuff before we could use the forms. That stuff was importing the forms modules into our module. At this point, you’ll get a good idea that almost everything in Angular is a module. This makes Angular very modular. I talked about building blocks, but we’ve already seen how we can make building blocks. Let’s imagine that we need a contact form in several different locations in our application (for some reason). We can create a contact form module and component.
This will create a module that we can basically copy/paste our contact form into. The only thing we need to do after that is to make sure our contact form module exports the component.
You can see that we export the component. So now, wherever we need to use the contact form, all we have to do is import the contact form module, and then we can use the <contact-form> tag in the HTML view. Now, if we need to make changes to that form, we can do it in a single place, and it will update wherever it’s used. We can also super easily and safely remove this from modules we don’t need it in.
The modularity that comes with Angular also allows us to easily break down large features into small parts. Then, like building something out of legos, we can use those small parts to build different things and organize them however we need to.
RxJS is Better than Promises; Come at me
I love RxJS, and I’m not afraid to say it. Observables are so much easier to work with than promises. Now, that’s not to say you can’t use RxJS outside of Angular, but it comes packaged with Angular by default. That’s also not to say you can’t use Promises in Angular, but honestly, why would you? Observables allow you to easily and concisely manipulate data streams over time. Things that change over time, like application state, can be more easily managed with observables. How is that so?
When you’re working with promises, if you have additional operations you need to perform on the data, you’re basically stuck with the .thenmethod. You can chain those methods but that gets messy. With observables, there are loads of different types of ways for you to chain operations and manipulate the data.
To ‘chain’ that thought to another one, An observable doesn’t get called until something subscribes to it. So you can encapsulate all your data manipulation into a single function and call it whenever you’re ready to consume it. This makes observables more declarative. Speaking of manipulating data, what kinds of data can come out of an observable? Loads! Remember, an observable is a stream of data over time; lots of different values can come out of it. Whereas a promise can literally only emit a single value once.
I’m tired of hearing people whine and moan about “observables are too hard, wahh.” Stop crying about it; you can learn new things. I believe in you!
TypeScript
That’s right, TypeScript is awesome, and Angular uses it. Now, Angular cannot come without TypeScript, they’re paired together for life, like two Swans. TypeScript comes with a ton of benefits. One of the things I love about TypeScript is being able to predict the shape of the data I’m going to be using. Being able to design data types using classes and interfaces makes my life a lot easier.
Classes and Dependency Injection
Angular is heavily class-based. All the components and services you’ll make in Angular will be classes. In fact, pretty much anything you do in Angular will be in a class. This allows you to take advantage of OOP principles. As we’ve already seen, we can easily re-use code in an Angular project. We can make code even easier to re-use using things like Inheritance. You’ll see that a lot with Angular lifecycle methods like the on init method.
I could go on about OOP principles all day, but that’s not really what this article is about. Just know you can make use of any and all OOP principles in your Angular application.
One thing I did want to talk a little bit more about is Dependency Injection (DI). This is key in Angular and gives you several advantages. One of the major ones is that we don’t have to create dependencies, but they’re created for us and then injected into the class. Let’s have a look at an example. Let’s say we have a service that makes a request to some backend service.
Now we want to use this service in our contact form component.
We can see that we can declare the backend service in the constructor of our contact form component, and now we can use it inside our class. This is easy to do because we don’t have to worry about creating dependencies for our dependencies. If you notice, the backend service has a dependency on the HTTP Client module. If we weren’t using DI, then the contact form component would have to create that dependency and then pass it to the backend service. However, DI solves that issue for us, and our code is better off for it.
DI also makes testing your components a whole lot easier since you can just inject your dependencies right into your tests. Your tests also don’t have to worry about creating the dependencies since they use the same DI method as your components.
Long Story Short
To make a long story short, Angular is the best, and I always use it for every front-end project. It’s easy to work with, and it has everything I could ever need to build any kind of application. It also helps abstract away monotonous tasks like config management, so I don’t really have to fiddle with that a whole lot. I also like the fact that all of my Angular apps are constructed in basically the exact same way. If I ever wanted to start using shared libraries, I would be able to do so easily and quickly using Angular.
I also really love using the observable patterns. I find them much easier to work with than promises as they provide me with a lot more flexibility. I can easily manipulate data and keep my code easy to read. Angular’s Dependency Injection also makes my life super easy. Whenever I want to include new dependencies in a component or service I don’t really have to worry about much other than importing the dependency into my class. Overall, Angular is a fantastic framework with loads of benefits to anyone who would want to use it. I don’t think it’s any harder to learn Angular than it is to learn React, Vue, Svelte, or any other front-end framework.
If you’ve enjoyed this article, I’d love for you to join my mailing list, where I send out additional tips, tricks, and newsletters!
If you found this article helpful, interesting, or entertaining, feel free to buy me a coffee to help me continue to put out quality content!
