Clubbing zones with angular
Download as DOCX, PDF0 likes51 views
The document explains the role of zone.js in Angular, emphasizing its function as a thread-local storage that helps manage asynchronous operations and change detection. It highlights how zone.js patches various async APIs to notify Angular when to trigger updates and respond to events, ensuring proper UI rendering. Additionally, it discusses the features of NgZone, which extends zone.js capabilities for executing code within or outside the Angular zone.
Clubbing zones with angular
- 1. CLUBBING ZONES WITH ANGULAR Thread Local Storage (TLS): Static and global data are shared across all the threads. If you modified a global/static variable it is visible to all the threads. Unlike global/shared variable if you create a variable in TLS, every thread has its own copy of the variable, i.e. changes to the variable are local to the thread. So what’s a Zone? Zone plays a major role in async tasks, and it’s a thread local storage for JavaScript VM’s. They are basically an execution context for asynchronous operations. They turn out to be really useful for things like error handling and profiling. But what exactly does that mean? Frameworks, such as Angular, need to know when all of the application work has completed and perform DOM update before the host environment performs the pixel rendering. In practice this means that the framework is interested when the main task and the associated micro tasks have executed but before the VM hands over the control to the host. I think that the main purpose of using zone.js in angular is to know when to render. Zone actually works on detecting changes. So, without zones, we don’t get any change detection. Angular uses the zone to patch async APIs (addEventListener, setTimeout(), ...) and uses notifications from these patched APIs to run change detection every time some async event happened. But actually zones are not required for change detection in general, they simply are the means by which Angular picks up changes and then calls tick so that any listeners for those changes are actually fired. In other words, Zone.js is a kind of wrapper around the whole angular application that patches (almost) all async APIs of the browser. Angular invokes automatic change detection every time execution of an event handler has been completed, and the use of zone.js allows Angular2 to get notified when that happened.
- 2. RxJS is a way of handling single or a series of events from an async APIs in your code. In Angular, we don’t have a $digest and $watch like cycle in the original Angular JS, so if we were to does something like this in Angular 2: Then the UI wouldn’t actually update properly, because ‘someProperty’ actually is updated outside of Angular’s zone. So we have to include something like this in order to get the correct updates: In other words, zone.run() is kind of like the new $digest(). API support: Zone.js patched most standard web APIs (such as DOM events, XMLHttpRequest, ...) and nodejs APIs (EventEmitter, fs, ...), and some nonstandard APIs, such as MediaQuery and Notification, etc. NgZone is a wrapper around zone.js, it extends some concepts of Zone. It actually wrapped a forked zone, we can see it from the full implementation.
- 3. NgZone first asserts that Zone.js has been patched, then it assigns itself this to self. _inner property is created and assigned to the current zone, in turn, _outer property is created and assigned to _inner value. The outer zone is used by NgZone to run code outside the angular zone, it is often used when you don't want the change detection cycle to run. Inner zone is used to run code inside the angular zone, this is where all our Angular code is executed when an async operation is caught change detection is triggered. Monkey-patched Hooks: It turns out that there are a few other hooks. In fact, those aren’t just hooks, but monkey- patched methods on the global scope. As soon as we embed zone.js in our site, pretty much all methods that cause asynchronous operations are monkey-patched to run in a new zone. For example, when we call setTimeout() we actually call Zone.setTimeout(), which in turn creates a new zone using zone.fork() in which the given handler is executed. And that’s why our hooks are executed as well, because the forked zone in which the handler will be executed, simply inherits from the parent zone. There are some other methods that zone.js overrides by default and provides us as hooks: Zone.setInterval() Zone.alert() Zone.prompt() Zone.requestAnimationFrame() Zone.addEventListener() Zone.removeEventListener() We might wonder why methods like alert() and prompt() are patched as well. As mentioned earlier, those patched methods are hooks at the same time. We can change and extend them by forking a zone exactly the same way we did with ‘beforeTask’ and ‘afterTask’. This turns out to be super powerful, because we can intercept calls to alerts() and prompt() and change their behaviour when we write tests. Also zone.js is useful for debugging, testing, profiling. It helps you see whole call stack if you face with some error.