Faster Angular Applications
- In fact, it gets invoked at least twice for each item in the list when we type a single character: – – Although we have calculated the numeric values for all the employees in the list and we have visualized them we’re recomputing them again, multiple times.
- The question is – how to tell to Angular to not recompute the numeric values for the employees unless it gets new lists for the two departments?
- By setting the change detection of to we will hint Angular that it should not run its change detection mechanism for this component unless it receives a new value for any of its inputs.
- If we invoke and pass as an argument (in the language of Angular, as an input): – – …the change detection will be triggered, since the initial value of the input was .
- However, if run: – – Although, we pass as an argument (or input) again, the change detection will not be invoked because after performing an equality check we will determine that the previous value of the input has the same reference.
@NG_Tutorial: Faster Angular Applications – Part 1. On Push Change Detection and Immutability. By Minko Gechev
On AngularConnect 2017 in London I gave a talk called “Purely Fast”. In the presentation I shown how step by step we can improve the performance of a business application. In the example I incorporated as many performance issues as possible which I faced over the past a couple of years developing enterprise Angular and AngularJS applications. After the presentation I got great feedback for the content so I decided to write a series of blog posts which aim to explain the content from “Purely Fast” in details.
In this part we will focus on immutable data structures and change detection.
The code for this blog post is available at my GitHub account:
A big issue in the modern single-page applications is reducing the initial load time. This includes reducing the number of bytes transferred over the network and minimizing the number of network requests. Last year I wrote a few articles related to reducing the bundle size (you can find them here and here). Although it’s always a good idea to invest time in exploring the bundles of our apps in details with tools like source-map-explorer and reducing its size, there are a lot of folks working in this direction.
For instance, the Google Closure Compiler team is constantly trying to provide the most optimal minification and dead code elimination, same for the webpack team. On top of that,…