I'd go with afterEachRefresh -> as Angular refreshes bindings and doesn't re-render.

I always wondered why AfterNextRender is not named something like AfterFirstRender or something.

It's very confusing to distinguish between the AfterNextRender and AfterRender, my colleague keeps forgetting what is what - with quite big impact.

I always wondered why AfterNextRender is not named something like AfterFirstRender or something.

It's very confusing to distinguish between the AfterNextRender and AfterRender, my colleague keeps forgetting what is what - with quite big impact.

true, same here

Yes, it is very confuse, I think there is an action we doing after something, like an action layer on other layer, so we can use on, like:

• onRender(( ) => { }) : everytime we render it, no matter where it is server or client
• onFirstRender(( ) => { }) : the first time we render

Same problem here...

Progressively replacing ngAfterViewInit with afterNextRender (following #49682, no SSR).

It's honestly a bit of a mess with the current names... combining: speed, IDE autocomplete capabilities, right function call is almost an NP-Hard problem! 😅

IMHO, too much error prone!

The team agrees that the name could be improved. The change will likely land as part of the stabilisation process of these 2 functions.

We decided to removed afterRender, see #60794.

@JeanMeche say: still afterNextRender is far from an ideal name. That Next makes no sense IMHO... except for confusing devs. 😅

Just an idea: how about a migration renaming afterNextRender to afterFirstRender / afterInitialRender / ... ?

In the end, they are still in dev-preview!

@mauriziocescon we can debate names but we shouldn't use anything that suggests "first" / "initial" - the afterNextRender hook executes in the next render cycle after it was created. Naming things is hard, but the current name exactly reflect what this hook does...

Well, I understand... just saying it can be easily misunderstood or not understood at all (especially if you're coming from the onMount(ed) world 😅 solid / vue / svelte).

But ok, it can be a point for the future as well... maybe following something like:

• definition of mounted,
• afterNextRender => onMounted,
• afterRenderEffect => onMountedEffect.

@mauriziocescon I think there is a misunderstanding here - afterNextRender is not an equivalent of mount-like hooks (again insisting on the fact that this is not about the initial render!). afterNextRender can happen any time in the component's lifetime - what matters is the timing of the hook's creation and change detection.

+1, was about to answer you on twitter.

afterNextRender is a global hook.
It fires after the CD process.

This is done for a reason, it's mainly a DOM hook you want to call once the DOM has stabilized

Ok, I might be completely off then... sorry for the confusion!

Let me explain how I (rarely) use it then: as an OnInit that runs only on the client without phases!

// onInit called client-side and potentially doing DOM manipulation 
private readonly domReady = afterNextRender(() => this.someInit());

I must admit I've never took a deep look at the phases part (flagged it as too complex in my mind). My bad!

I wonder: would you be so kind to elaborate on what I'm doing wrong? Or correct my mental model regarding it? 🙏

If it's for DOM manipulation it's fine.

The phases are here to prevent multiple reflow by ordering the multiple after render callbacks. earlyRead > Write > ReadWrite > Read.

Yeah... that part was more or less clear (again haven't checked all the details... and I'm not a real expert of reflows)!

What I wonder is: maybe designed with a different purpose in mind... but isn't afterNextRender(() => this.someInit()) logically equivalent to an onMonted? Still don't get this part... but if I set a breakpoint, it seems to me it's behaving like this!

Confused now...

onMounted is more like the first invocation of AfterViewChecked which is scoped to the rendering of the component.

Say: what onMounted (solid / vue / svelte) does is clear enough to me! And that's mostly what I'd like to use.

What is not clear to me is the relationship between afterNextRender and onMounted.
I see 2 outcomes:

1. afterNextRender offers more possibilities than onMounted (and you should learn about those), but it can be used as onMounted (more or less logically equivalent),
2. afterNextRender is totally different compared to onMounted and you're abusing it; see this counterexample for afterNextRender(() => this.someInit()) where __ this_bug __ happens!

afterNextRender somehow offers more possibilities.

Imagine you want to read the size of your component, but that size directly depends on the size of a neighbouring component (like with flex ratios).
Reading the size in afterViewCheck is too early because it'll change after when the neighbouring component is rendered. Reading it after everything is rendered, is actually the best time for it.
And since you might have several DOM apis that read/write the DOM it's important to have them ordered to prevent unnecessary reflows.

Ok, I checked the phases part in the doc and indeed it's clear the reason of the name now! Thanks!

Say: maybe it's just me, but I have the feeling it targets sort of lib / advance cases... rather than more common ones in pure DEV land "hey I need to do some basic DOM manipulation (elRef) and I want it to be safe while using SSR (or even just future proof)".

The fact all phases are optional doesn't help either (yeah... more APIs then).
So I got confused! 😵‍💫

Anyway: thanks!

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}