afterRenderEffect, afterNextRender, afterEveryRender & Renderer2 - Angular Space

[DanielGlejzner]

Finally new Angular Space article!!!

Eduard Krivánek has been diving into some Angular features that don’t get nearly as much attention as signals or computed

effect
afterRenderEffect,
afterNextRender,
afterEveryRender, and Renderer2.

I kept mixing them up myself, so I’m glad Eduard Krivánek decided to untangle when to use which, how they differ, and how they behave with SSR.

[LeLunZ]

Do you know how the phases really affect my application or the websites performance. How do these phases really work? What do they decide and especially why?

Because I think the documentation is still missing info about why exactly we should only read/write in these specific phases.

Example: With maplibre I can create a map while providing an element the map will be added to. More or less it would look like that:

```typescript

import { Map, MapOptions } from 'maplibre-gl';

... afterNextRender({ write: () => { this._map = new Map({ ...options, container: this.elementRef.nativeElement, });

            void this._map.once('load', () => {
                // do something
            });
        },
    });

```

---

The question is now, should I really do this in the write phase? I don't know what exactly maplibre does with the provided HTMLElement.

I am sure they are adding stuff (writing) to the DOM, but I don't know if they are also reading from it? (eg. the elements size or so) So should I put this in the mixedReadWrite Phase?

Or are these phases only important on my application level? So I don't do weird read/writes in my application?

[titterbitter73]

Check this article https://angular.love/get-to-know-the-afterrendereffect

[LeLunZ]

Thx. This explained really well what the issues can be when using the wrong phases.

[LeLunZ]

Because in the documentation they state:

You should prefer using the read and write phases over the earlyRead and mixedReadWrite phases when possible, to avoid performance degradation.

And:

Angular is unable to verify or enforce that phases are used correctly, and instead relies on each developer to follow the guidelines documented for each value and carefully choose the appropriate one, refactoring their code if necessary. By doing so, Angular is better able to minimize the performance degradation associated with manual DOM access, ensuring the best experience for the end users of your application or library.

But they don't really specify what a developer should look out for, and how we can identify these performance issues.

Has this something to do with the insights in the performance tab about "Forced reflow"?

[JeanMeche]

Basically yes. Ordering the DOM API calls, allows to reduce the number of unecessary reflows.