DEV Community

loading...
Cover image for Using Hot Module Replacement in Angular 11

Using Hot Module Replacement in Angular 11

iamscottcab profile image Scott Originally published at scott.cab ・2 min read

Angular 11 was released today and with it comes a large number of performance upgrades, bugfixes (including the third most popular issue) and improved logging.

Not only was the upgrade from Angular V10 to V11 painless but I wanted to share the new Hot Module Replacement feature. This has been exposed on the CLI if you hadn't tried it in previous versions, so now is a great time to dive in and give it a go.

For those unaware this feature is not native to Angular, rather webpack. If you'd like to read more about it you can find their documentation here. In short you can think of Hot Module Replacement as a more advanced version of a file watcher, only replacing the modules that need replacement and (where possible) preserving state. So what does this look like in action? See the videos below (which are best viewed full screen).

Classic Angular Reloading


The above should look very common for front end developers. We are testing out our model binding in our form. We decide that it's working well but we want to change the label on our input. Doing so forces a refresh of the page and we lose our state.

Hot Module Replacement in Angular


With the Hot Module replacement flag used we see a slightly different story. The initial flow is the same. We test our model binding and again want to change the label on the input. This time the Hot Module Replacement preserves our state and our input still has our user generated value. Nice!

Adding Hot Module Replacement & Use Cases

In my current project I've nominated that we additively pick up this new feature. For most uses cases the standard watcher works just fine so retooling for a slightly better development experience for some might hurt others in the team. I propose you add a new script to your package.json while you're adopting this to see if it suits your needs. Perhaps something like "serve:hmr": "ng serve --hmr". Then your team can either run npm start for their normal experience or npm run serve:hmr. This gives you the best of both options and allows you to pick and choose which reload strategy based on the functionality you are building out.

Consider using Hot Module Replacement when:

  • You have a complex flow that you do not want to restart.
  • You are making cosmetic changes and want to test on non-standard input (such as long strings).
  • You are fixing / tweaking API calls and want to reuse the same form values.

What else do you like about the Angular 11 update? Let me know on Twitter or check out my content on my site.

Discussion

pic
Editor guide
Collapse
dzhavat profile image
Dzhavat Ushev

HMR is great and I really like it as well! However, it can also cause cause memory leaks (in development) if the app is not build with it in mind. I wrote a post about it:

Collapse
muuvmuuv profile image
Marvin Heilemann

Could you explain why NG11 CLI still says this "The project will still live reload when HMR is enabled, but to take full advantage of HMR additional application code which is not included by default in an Angular CLI project is required.". Would like to know which are those additional steps for an NG project.

Collapse
ajinspiro profile image
Arun Kumar

I hate HMR... When our app gets large it won't work as promised - yeah it's true that bowser tab wont reload preserving state, but in console a ton of things will break so I m forced to manually reload after HMR finishes it's stuff... Been using it with vue... I'm looking for how to get rid of it

Collapse
raddythebrand profile image
Raddy

That's pretty cool. It's good to hear that there are no breaking changes. I need to upgrade and give the πŸ”₯ module replacement a go. Thanks for sharing