Angular — Three features that you should consider when starting a new project

Have you ever built an Angular project from scratch? Here are several features that you should consider at the very first moment when you are starting a new project. Adding these features later to an existing project will be very costly.

Lazy Loading

Lazy loading refers to the design to delay the loading of module until it is actually needed. By default, Angular loads everything when users visit your application, including pages that are not yet visible. It leads to extra loading time. A better design is to only load the page when users visit it. Yet, in the world of Angular, you cannot just lazy load a page. You have to group the components, pages and services into different modules and lazy load the whole module in a specific trigger point. If you haven’t ever thought about lazy loading at the beginning and you just put everything to your root module, it will be extremely difficult to add this feature later on when the application size grows larger. It is because you will need to decouple you components and services to avoid shared logic between different modules. It will normally need a revamp on the whole architecture to enable this feature on an existing application.

Server Side Rendering

By default, your Angular application is rendered from the client side. It means when users visit your website, they receive only pure JavaScript. The browser will then execute the scripts to render the page. A major problem here is SEO. Most search engines don’t execute JavaScript. It causes problem for them to index your website. Server side rendering refers to the mechanism to execute the JavaScript and render the first page from your server. Hence, on top of JavaScript, crawlers will now also receive the HTML for the first page they visit. The official solution for server side rendering is Angular Universal. If you haven’t thought about this at the beginning, here are several problems that you will need to deal with later. First, not all components and libraries support server side rendering. You will need to replace all of them with something else. Secondly, it is guaranteed to break your existing client side authentication flow. You will need to redesign your authentication mechanism. Lastly, you will be very screwed if you have lots of dynamic data. You will need to redesign the loading mechanism such that those data can be loaded from the server side.

Shared State Management

Have you ever came to a scenario that you need to share some states between several components or pages, such as data between the navbar and your body? Or some concurrency data that keep refreshing from the background? The traditional Angular way for these use cases is to use a service. Yet, the major problem of using a service is that you will need to manually notify your components for state change. For example, when there is new data coming in, you will need to emit an event or call callbacks to handle the data change. It will become very difficult to manage when you have many different types of data. One popular way to handle these use cases is NgRx Store. NgRx Store is RxJS powered state management for Angular applications, inspired by Redux. Integrating NgRx Store to an existing application is difficult as it requires a huge change of logic from using callbacks and events to the RxJS ways. If your application is going to have these kind of use cases, you are recommended to think about state management before you start to do the coding.

That’s it. Thanks for reading! Any comments would be highly appreciated. :D

Web developer from Hong Kong. Most interested in Angular and Vue. Currently working on a Nuxt.js + NestJS project.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store