Wait I thought cWRP *just* to help interop w/ 3rd party, non-react utilities? Isn't manually updating state from props in cWRP anti-pattern?
-
-
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
-
I think that's probably true, but it's not inherent. "I have this state lying around" is a good way to lock into hard-to-optz APIs.
-
Agreed, but backwards compat was a goal for 16 w/ Fiber so it was already ~locked in, maybe that could change if a better API is proposed
-
Functional components don't have hooks. How is cWRP discussion relevant to functional components? What lock in are we talking about?
-
This part wasn't about functional components
Locked in to the cWRP API with old + new props, assuming that there's unwanted overhead there -
Which I'm saying I don't *think* there's really overhead because we already have old + new props at this point for other reasons
- 11 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.