fwiw, the reason Ember is so pushy about computed properties is to avoid your #3.
-
-
It's useful, rarely, when processing the props is CPU-intensive. Can happen in certain situations
-
You also have access to both current *and* next props in cWRP, which you don't have in render.
-
You do if you stash them. Better to do that when you need it then make the framework snapshot them always, I think.
-
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
-
Depends on the architecture, but Glimmer can avoid work in the general case if we don't have to unconditionally pass the old snapshot.
-
I mean, if the component doesn't actually implement the hook the framework doesn't have to do anything, right?
-
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. -
I think that the old props (internally, memoizedProps) would exist at the point cWRP is called regardless due abortable work in Fiber
- 16 more replies
New conversation -
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.