My name is Thomas Desmond: Full Stack Developer, Speaker, Educator, & Thinkster.io Author.

Category: Angular

Managing your RxJS Observable subscriptions in Angular with SubSink

Angular Logo

RxJS and Observables are HOT in Angular now. Many of us have started using them and they are not too difficult to pick up and begin using. But there is probably a small piece you are forgetting…Unsubscribing to your subscriptions.

Way too often I open up an Angular Component and inside the ngOnInit() I see a subscription that is never being unsubscribed from. Something like this:

Above we have our userService, and we are subscribing to the GetAllUsers method in our service. But we never assign our call to any variable. This is an easy way to know we are never unsubscribing from this call.

Now you may have many calls like this in your app and it works fine. You don’t notice any ill effects. But this is bad practice. If we subscribe we need to unsubscribe. We should not leave subscriptions laying around. We don’t want to leave tons of open subscriptions. So what should the above code look like?

Above, we created our sub variable to hold onto the subscription. And in the ngOnDestroy lifecycle hook, we unsubscribe. This looks pretty easy. Just a few extra lines of code. But what if we had lots of subscriptions. Having to add many new component level variables can clutter up our file quickly. And we already have a hard time remembering to unsubscribe, is their an easier way?

This is where the package SubSink developed by Ward Bell comes in. Managing subscriptions should not be difficult and SubSink makes it easy. The same code above using SubSink would look like.

There are two easy ways we can use SubSink shown above. In Method 1 we directly add our subscription. While in Method 2 we are using a setter to add the subscription to the sink. Both end up doing the same thing functionally but we can use either syntax.

In the ngOnDestroy, we have one simple this.subscriptions.unsubscribe() call that does all the unsubscribing to all of our subscriptions for us. SubSink makes it much easier to manage our subscriptions and gives us no excuse to not remember to unsubscribe from them.

SubSink makes our lives easier managing the subscriptions for us. Making our code easier and less cluttered is always a big win!

If you are an Angular developer check out my post on Must-have VS Code Extensions for Angular Developers!

Must Have VS Code Extensions for Angular & Typescript

Let’s take a look at the VS Code extension that I use regularly when developing Angular code. I like my extension to make me a more productive developer. Many of these could be helpful outside of Angular development but these are some that I like.

#1 Angular Snippets

This extension is great because it gives you access to many useful Angular, Typescript, and even HTML. I find myself using the HTTP related snippets often. Snippets are great because you no longer need to memorize complex syntax and can now focus on the development.

#2 Material Theme Icons

Material Theme Icons is great because it changes all the icons used throughout VSCode with beautiful icons. It makes it much easier to discern between the different files in your project. Not only does it have icons for the different file types but also folder types. I highly recommend this extension to make your editor look nice and clean.

#3 Bracket Pair Colorizer 2

Bracket Pair Colorizer is one of the first extensions I install when if I come across a machine that does not have it. It changes the colors of all your brackets, parenthesis, etc. It even creates a line that connects each pair to one another. Just make sure to install version 2 because that is the one being actively developed.

#4 Typescript Importer

This one is helpful when working in our Typescript components. It will auto-import definitions for us. So if we start using a new service or a new model in our component on the first use it will automatically bring in the import. Again, this helps us focus on the development work not having to jump around the file importing new things.

#5 Angular Language Service

Angular Language Service is another great Angular extension. This one is developed by the Angular team itself. It helps make VSCode smarter with its auto completes and giving hints about what to do next in your Angular code. This one is a must-have for Angular development.

#6 Code Spell Checker

This is another extension that is helpful for any development done in VS Code. It checks the spelling of your code even for your camelCase variables. It is great at finding common spelling errors that we make in our code. This can be extremely helpful in finding those nasty spelling error bugs. Definitely add this extension to your VS Code if you have not already.

Two Angular 10 projects, same package.json, one project has 281 vulnerabilities the other has 0

The other day I was messing around with Angular and upgraded a project from Angular 8 to Angular 10. I wanted to see the new hotness! Upon upgrading my fairly simple application I was hit with 281 low vulnerabilities reported when I performed an ‘npm install’.

281?!? How could this be? I had zero before. Granted they are low but come on this is way too many. I scoured the internet and had trouble finding someone else who had the same issue as me. I thought to myself it must be because Angular 10 is so new.

So, I took the debugging into my own hands. I created a brand new ‘ng new’ project. Upgraded it to Angular 10, added all the same packages, and what do you know 0 package vulnerabilities. Two Angular 10 projects, the same set of packages, wildly different set of vulnerabilities.

This created a great deal of confusion for me. So I ended up taking the fight to Reddit. I presented my problem hoping the great ether of Reddit would be able to find a solution for me.

And you know what, they did! After a few failed attempts to fix the problem someone suggested deleting my entire node_modules folder and the package-lock.json file. Simple stuff right, I’ve done this before actually on different projects. How could I have forgotten this simple trick.

After deleting the node_modules and the package-lock.json file. I tried ‘npm install’ again and behold 0, zero, goose egg, vulnerabilities. Apparently npm is not the best at cleaning up after itself or taking the very latest packages.

Deleting node_modules and package-lock.json to have them recreated by an ‘npm install’ will not solve everyones problems. But if you are seeing issues revolving around npm not pulling down the very latest versions of packages, this very well may be a good solution for you.

App Module vs Core Module vs Shared Module vs Feature Modules in Angular

Angular Icon

Angular development best practices indicate we should break our applications into modules. Modules in Angular refer to a place where we group like components, services, directives, pipes, etc for our applications.

The easiest to think about would be Feature Modules we simply break these up by feature or domain. But what about the App Module, Core Module, & Shared Module?

What should we put into each of them? What components should live in each of them? Why do we need all of them? Let’s take a look at each of the types of modules and what they are used for.

App Module

Lets first take a look at the App Module in Angular. The App Module can also be called the root module. Every app must contain at least one module and that is the App Module. We launch our applications by bootstrapping the root module.

We want to keep our App Module pretty compact. There should not be a lot of content in the App Module or App Component. We want to encapsulate our application into domain-specific modules, the Core Module, & the Shared Module, which we will look into now.

Core Module

The Core Module is where we want to put our shared singleton services. So the services that we want only one instance of while having them shared among multiple modules should live here.

The Angular injector creates a new instance of a service for each lazily loaded module that it is provided in. We want to keep our singleton services in the core module so only one instance is ever created. We do not want to spread them out in our feature modules.

Another piece of our application that should live in the Core Modules are app-level components. A good example of an app-level component would be the navigation bar. Only the app needs to know about our navigation component.

We do not want to put components used throughout the application inside of the Core Module. We have the Shared Module for that and we will look at that now.

Shared Module

The Shared Module is where we want everything to live that is shared throughout the application. Components, directives, guards, & pipes can all live in the Shared Module.

An example of something commonly found in the shared module would be a loading spinner. If you have any other components that you want to be distributed throughout your application the shared module is where you want to keep them.

It is also common to import and export Angular built modules inside your Shared Module if you need to access them in multiple locations. Because Shared is imported into many of your Feature Modules it’s common to import/export Common Module or Angular Material modules. Import/Export the modules once in Shared Module and now anyone that imports Shared will have access to them.

Feature Modules

Applications commonly have multiple Feature Modules. Depending on the size of your application you may have A LOT of Feature Modules. Breaking things up into domain-specific areas can help in the long run for development.

One of the main reasons to break your features up into different modules is lazy loading. If you want to learn more about lazy loading check out the Angular documentation on Lazy Loading Feature Modules.

Laptop Code

Now you have a better understanding of how to separate your different modules in Angular. For more on modules check out the Angular Introduction to Modules.

What are Structural Directives in Angular?

Structural Directives in Angular modify what is displayed in a view. They live directly in the HTML. They modify our HTML by adding, removing, or manipulating elements.

Why are they called structural directives? It is because they modify the structure of the Document Object Model (DOM).

Structural directives are easy to spot. They will begin with an asterisk (*). And the two most common structural directives are *ngIf and *ngFor.

Above is how we use a *ngIf. The if statement will evaluate on TheTomBomb and only if that is true will it include “Thomas is the best” into our DOM and viewable to the user.

If TheTomBomb evaluates to false “Thomas is the best” will not display. And not only that, but it will also not be present in the DOM.

The above *ngFor will print out a list of website url’s. The websites variable is a list of websites and we will loop of that and generate a new <li> for each one in our collection. So a new <li> element will be created in the DOM for each item in websites.

Structural directives are popular and give us added capabilities inside of our HTML. *ngIf is perfect for showing and hiding data. *ngFor is great when we need to generate repeated HTML.

To learn more check out the Angular documentation on Structural Directives.

© 2020 The Tom Bomb

Theme by Anders NorenUp ↑