Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Consistent useCallback implementation in ReactDOMServer #18783
Conversation
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit ab9ee0f:
|
|
Fine for consistency but I think the implementation of useMemo is actually wrong here. We should just break it and never memoize. This is not reliable anyway since suspense will clear it. There are no guarantees that it'll memoize. If anything we should make it less predictable on the client to ensure that these abuses don't land in the first place. E.g. occasionally drop it in DEV. It's not worth memoizing everything in the whole page just in case something calls setState in render during initial render, which should be a warning anyway since it only exists for update purposes. So it should never happen on the server initial render. In fact, we should break the whole implementation of setState during initial render on the server and free up that extra work. I think I know which internal callsite you're referring to but that's poorly structured code relying on setState in render. We should restructure/rewrite that code. |
Details of bundled changes.Comparing: 5153267...ab9ee0f react-cache
Size changes (experimental) |
Details of bundled changes.Comparing: 5153267...ab9ee0f react
React: size: 0.0%, gzip: -0.0% Size changes (stable) |
alexmckenley
merged commit e71f5df
into
facebook:master
Summary
In ReactDOMServer we implement both useMemo and useCallback. The React docs mention that
useCallback(fn, deps)is equivalent touseMemo(() => fn, deps), however this is not true today as useCallback completely ignores the deps argument.Although the docs also mention that there are not semantic guarantees around memoization for useMemo (and subsequently useCallback), having the implementation differ between these hooks in the server environment can be confusing and lead to hard to track down issues that appear only during server rendering.
Also after reading the docs, I'm not absolutely sure if useCallback is expected to provide semantic guarantees based on the inputs changing. This is very clear for useMemo, but the behavior for useCallback seems somewhat up for debate, since its not explicitly called out.
I think it would be worth updating the docs to make this clear since I've already seen examples of devs relying on callback references to be stable (which is how this came to my attention initially).
Test Plan
Added test case in ReactDOMServerIntegrationHooks-test.js
Also verified that this prevents an infinite render loop on the server when used with code that relies on callback references being stable.