But then you don't need the hook at all
-
-
It's useful, rarely, when processing the props is CPU-intensive. Can happen in certain situations
1 reply 0 retweets 2 likes -
Replying to @jlongster @wycats and
You also have access to both current *and* next props in cWRP, which you don't have in render.
1 reply 0 retweets 2 likes -
Replying to @aweary @jlongster and
You do if you stash them. Better to do that when you need it then make the framework snapshot them always, I think.
1 reply 0 retweets 0 likes -
Replying to @wycats @jlongster and
I don't think it makes forces the framework to snapshot them, it's just a lifecycle that's called at the right moment when both exist
1 reply 0 retweets 0 likes -
Replying to @aweary @jlongster and
Depends on the architecture, but Glimmer can avoid work in the general case if we don't have to unconditionally pass the old snapshot.
1 reply 0 retweets 1 like -
I mean, if the component doesn't actually implement the hook the framework doesn't have to do anything, right?
1 reply 0 retweets 0 likes -
Replying to @AdamRackis @wycats and
And that of course assumes
@aweary is wrong, which I don't think he is - prolly just a method the fw calls with values it already has.2 replies 0 retweets 0 likes -
Replying to @AdamRackis @wycats and
I think that the old props (internally, memoizedProps) would exist at the point cWRP is called regardless due abortable work in Fiber
2 replies 0 retweets 1 like -
Replying to @aweary @AdamRackis and
Maybe
@dan_abramov knows if that's a fair assumption though
At the very least they don't seem to exist for only this API1 reply 0 retweets 2 likes
It seems good to be able to avoid stashing off old values if talking about simple, functional components.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.