DEV Community

Cover image for Episode 23/28: effect() outside Change Detection, RFCs Q&A with Angular Team
ng-news for This is Angular

Posted on

Episode 23/28: effect() outside Change Detection, RFCs Q&A with Angular Team

Effects in Signals will be decoupled from the Change Detection. The Angular Q&A provided answers to common questions about the latest RFCs.

Decouple effect() from Change Detection

Signals are tightly coupled to the template, which makes them not very suitable for generic usage.

We see this with the signal and computed function. They do nothing, unless we call them within a template or use them in an effect.

The effect plays a crucial role if we need side-effects but it comes with a constraint. It only runs during the change detection. In other words, we cannot run a signal-based side-effect outside of the change detection. That's going to change.

Alex Rickabaugh published a new PR which intends to remove the execution of the effect in the change detection. Instead, the effect runs as an asynchronous task. To be precise, the effect should run as a microtask, which is like a native Promise.

refactor(core): decouple effects from change detection #51049

Previously effects were queued as they became dirty, and this queue was flushed at various checkpoints during the change detection cycle. The result was that change detection was the effect runner, and without executing CD, effects would not execute. This leads a particular tradeoff:

  • effects are subject to unidirectional data flow (bad for dx)
  • effects don't cause a new round of CD (good/bad depending on use case)
  • effects can be used to implement control flow efficiently (desirable)

This commit changes the scheduling mechanism. Effects are now scheduled via the microtask queue. This changes the tradeoffs:

  • effects are no longer limited by unidirectional data flow (easy dx)
  • effects registered in the Angular zone will trigger CD after they run (same as Promise.resolve really)
  • the public effect() type of effect probably isn't a good building block for our built-in control flow, and we'll need a new internal abstraction.

As effect() is in developer preview, changing the execution timing is not considered breaking even though it may impact current users.

RFCs Q&A with the Angular Team

We shouldn't forget the "older" RFCs, which are still open. The first is about integrating control flow commands directly into the template syntax. The second one is about the possibility of deferring the loading of components.

An official Q&A took place, where members of the Angular team explained these RFCs and answered questions.

The pattern where we combine async and *ngIf for Observable will not be necessary anymore and will get a better version with the new syntax.

We've learned that Angular looked into JSX but will not follow its path. The reason is that JSX is executed code that doesn't fit Angular's approach. Some ideas from JSX might land in Angular.

Alex Rickabaugh, Angular core lead, made vague comments about the future of forms. They are looking into ways to unify the current ones, but this is a long-term goal.

Live Q/A with the Angular Team | Control Flow and Deferred Loading RFC - YouTube

Join the Angular team for a live stream as answer questions and discuss feedback for the two recently announced RFCs:- Control Flow 🔗 https://github.com/ang...

favicon youtube.com

Minor Releases

In terms of new releases, it was pretty quiet. Playwright, an E2E testing framework, moved up to version 1.36.

ChangeLog

Top comments (0)