5 Things that Improve your Angular Codebase Right Now!

”We like to do things in our own way! We don’t like to follow the rules of someone else!”

Why did you choose angular then? If this is your organization, I highly encourage you to re-consider the choice of your fronted-framework. There are a lot of other frameworks out there, that suite your expectations a lot better. You will not be happy with angular, neither in the short nor in the long run!

Example: File Names

One example of these rules is the naming of files.

Files in angular follow a very specific theme, called a naming convention. Every file that contains an angular-structure, like a component, a module or a pipe, is named like this:

 [name].[structure].[file-extension]

So if we want to create a component to display our customers, the name would be “customer”. The structure would be component an the file extension is either “.ts”, “.css” or “.html”. For example:

 custumer.component.ts

If you are using the angular-cli, that part is taken care of, by using the ng-generate commands to create any structure. The resulting file will automatically follow the naming convention. If you want to learn more about the angular-cli and the ng-generate command, check out my tutorial on the angular-cli.

Feature Modules

One category of modules are the so-called “Feature Modules”. As you probably have guessed already, they are created to contain one specific feature.

These modules are created in a separate folder with the name of the feature.

For example, the feature-module for the feature “feature” would be placed into a directory called feature. The module file itself follows the naming convention mentioned above: feature.module.ts

But why do we create feature-modules?

Well, first of all, they provide a way to structure our code in a way that is reasonable and easy to understand. They also separate different features completely. That way there can’t be any weird overlap that could cause confusion and potential bugs.

Another great advantage of feature-modules is that they allow us to use a technique called lazy-loading. With lazy loading, we only download a module to the client device, if the module is actually needed.

For example, if we have an administration-section for a blog, it would not make much sense to serve the code for the admin-section to every user visiting the site.

Instead, we separate the admin-section into a feature-module and load it using lazy-loading. Now, if a user is entering the site, he only has to download the code for the blog-section. Only if he is navigating to the admin-section, the additional JavaScript code is downloaded.

Core and Shared-Module

Using feature-modules, every component, directive or pipe is encapsulated in a separate module. That way, it can’t be used elsewhere in our application, without importing its module.

But that would not make any sense, would it?

Imagine our feature module of the blog section would have to import the admin-module just to use a simple utility-directive. That would not only be a quite confusing structure but would also eliminate the benefits of lazy-loading.

Shared-Modules

What we should do instead, is to create one or more shared modules that are meant to be used by feature modules. A common use case for this are utility components, directives or pipes.

For example, we could create a text-formatting module, that would contain a bunch of pipes to properly format text in certain ways.

That module could then be used by all of our feature modules, without breaking the strict encapsulation of the modules themselves.

Core-Module It turns out, feature and shared modules are not enough to cover all of our needs.

We also need a pace for all of our application-wide singleton services.

That is what the core-module is for. It is placed in a directory called “core” and is name CoreModule.

Inside of the core-module we provide all application-wide singleton-services we might need.

The core module is then imported into the app-module.

That way, out app-module stays nice and tidy.

But the core-module is not just for services. Everything that is used application-wide but to simple to create a new shared-module for, can be declared in the core-module.

An example for that are loading-spinners for the start of the application. They are never used anywhere else so creating a extra shared-module would be kind of overkill.

Provide Private Services in your Component

Most services in angular are designed to act on a global scope. They are then provided at an application level (AppModule).

This makes sense if the use of the global-singleton-pattern is required. For example, if your service is responsible for caching things. In this case, you want one global instance. Otherwise, each component has its individual cache. This is because of the scoped dependency injection in angular.

But there are definitely services that do not need to be provided globally. Especially if they are used by just one component.

In that case, it can make sense to provide that service inside of the component, instead of the service. That is if the service is directly tied to that component.

Otherwise, you should try to provide the services in a module, so that can only be accessed from everywhere it is needed.

That way, services can be related to features (feature-modules), which makes them easier to find and understand in the right context.

Also, they are contained by a feature module, which —again— enables lazy-loading capabilities.

It also minimizes the risk of dead code, in case the only module that uses the service is deleted.

State

When it comes to state, there are a bunch of problems that emerge from each component having its own state.

Simply put, you lose track of which component is in which state pretty fast. That can make debugging a quite hard task and results in these kinds of bugs, nobody wants to have.

Especially in large applications, this can be a huge problem.

More on the topic of centralized state in chapter 5.

Avoid Promises

RxJs partly overlaps with its functionality with the standard JavaScript promise. Both are meant to handle asynchronous code.

But rxjs can do so much more! Other than promises, the so-called rxjs-observables can resolve to more than just one value. Instead, they are a stream of values, we can contentiously listen to.

Of course, it is also possible to pass only one result to that stream, which creates this overlap with the promise.

So what should we use? The simple promise, that allows us to use the TypeScript await operator? Or the much more powerful rxjs-observables? Why not both?

Those questions are not easy to answer. In fact, people have different opinions on this.

Here is what I think:

I really like the style of the await operator for promises, but I think we should stick to the opinion of the framework. And this opinion is quite clear.

Use rxjs everywhere.

We can see that, by looking at the angular HTTP-client. It returns rxjs-observables, even when it is clear, that a HTTP-call can never result in more than one response.

I also don’t think that mixing it up is a good solution. That way, you have completely different implementations, that are hardly compatible with each other in different parts of your application. Depending on who wrote the code. After all, that is exactly what we try to avoid by using angular.

Use the Async Pipe

As stated above, rxjs-observables are a little bit more complex. Not using them correctly can lead to serious bugs.

The most common mistake I make is forgetting to unsubscribe from the observable. This does not only lead to memory leaks, but also unnecessary calculations and potential unexpected changes in the state of your application.

 public result;
  ngOnInit() {
    this.http.get('').subscribe(result => {
      this.result = result;
    })
  }
 

But avoiding this mistake is quite easy in angular. All you need to do is to use the angular async pipe. This pipe will automatically unsubscribe from the observable, once the component is destroyed.

   public result$;
  ngOnInit() {
    this.result$ = this.http.get('');
  }
 

And bind in the template to the observable using the async pipe:

<p>{{result$ | async}}</p>

A nice side effect of this is, that the code looks a look simpler and cleaner, as well.

So should you just use Redux/ngrx?

Again, there are millions of opinions out there. After all, you will have to come up with your own one.

But here are is my point of view:

Despite of the hype, I don’t think that everybody should start re-writing their apps to integrate redux. Even if you start from scratch, I don’t think redux is the way to go a lot of time.

Of course, that highly depends on the kind of application you plan to build.

Are you building large applications with hundreds of components, developed by a large team? Sure, go ahead and use redux. It will save you a lot of trouble.

Are you building medium sized-applications? Not larger than the average app on the app store? Working with up to 10 people? Maybe redux is not for you. Redux comes with a ton of boilerplate. A TON! Pumping up your application (seriously, it can triple the number of files you have) is probably not worth it. At least that is what I think. I would prefer a slim code base at any time.

Also, there are other possibilities out there. For example, you could just create observable store-services. You can read more about that in this great article by Jure Bajt about state management in angular with observable store services.

Are you building a small application? A side-project or a prototype even? Don’t touch redux! The value that redux could provide in those situations is almost zero. At the cost of creating hundreds of boilerplate-files. You will not only make your app a lot more complex than it needs to be, but it will also take away all the fun you might have had otherwise.

As you can see, I am not a fan of boilerplate code.

But there is hope!

There is currently a library in the works, that promises zero boilerplate-code while still using redux with ngrx. It is called angular-ngrx-data and is maintained by John Papa. Definitely, check that out!