[fresh] Reset useMemoCache when size changes #30663

poteto · 2024-08-12T15:39:30Z

Stack from ghstack (oldest at bottom):

During development when adding or removing code, it is common for the
cache size to vary between refreshes. Rather than warn like before,
let's simply and safely reset the cache completely whenever its size
changes between renders. In practice, in non-development environments
full invalidation should never happen since the only consumer of uMC is
compiled code – which always emits a static call to uMC with a fixed
size. However, for consistency we continue to reset the cache as well.

[ghstack-poisoned]

vercel · 2024-08-12T15:39:32Z

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 14, 2024 6:54pm

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. ghstack-source-id: 2f17b95 Pull Request resolved: #30663

react-sizebot · 2024-08-12T15:43:32Z

Comparing: dd8e0ba...e007738

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	+0.11%	1.82 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	500.37 kB	500.40 kB	+0.01%	89.80 kB	89.81 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	+0.05%	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	=	507.50 kB	507.53 kB	+0.01%	90.96 kB	90.97 kB
facebook-www/ReactDOM-prod.classic.js	=	595.24 kB	595.27 kB	=	105.55 kB	105.56 kB
facebook-www/ReactDOM-prod.modern.js	=	571.54 kB	571.57 kB	+0.01%	101.75 kB	101.76 kB

Significant size changes

Includes any change greater than 0.2%:

Expand to show

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
test_utils/ReactAllWarnings.js	=	64.07 kB	63.92 kB	=	15.86 kB	15.81 kB

Generated by 🚫 dangerJS against 237ebef

poteto · 2024-08-12T15:43:45Z

packages/react-reconciler/src/ReactFiberHooks.js

+      data = memoCache.data[memoCache.index] = new Array(size);
+      for (let i = 0; i < size; i++) {
+        data[i] = REACT_MEMO_CACHE_SENTINEL;
+      }


An alternative approach might be to append a debug property on the fiber during fast refresh to reset the cache only when Fresh actually kicks in. That has the advantage of resetting the cache during a refresh even when cache size is the same (ie new code happened to result in the same number of cache slots)

This seems to be the better approach to me.

React shouldn't be throwing prod-only errors.

Feels very likely there are types of changes where the memo size doesn't change (e.g. some literal such as a style is updated in the component)

What does useMemo do if its implementation changes? Does it just keep its cache entry? Seems like it would need to reset for the same reason.

useMemo always drops the cache on hot reload. Seems like we should do the same for uMC? We assume memoization is not essential for the logic and can be reconstructed. This also tests that the component logic is resilient to it somewhat.

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. ghstack-source-id: 48c5b9c Pull Request resolved: #30663

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. ghstack-source-id: bffbd19 Pull Request resolved: #30663

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. ghstack-source-id: 48c5b9c Pull Request resolved: #30663

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. ghstack-source-id: 3fa6248 Pull Request resolved: #30663

josephsavona

Throwing in prod for something that works in dev can lead to problems. I think we might need to either a) specifically limit this to fast refresh in dev (so that it errors otherwise) or b) just reset even in prod.

But I can see the argument that since you are never supposed to use this API directly, that it's maybe fine for it to have different behavior in dev/prod.

poteto · 2024-08-12T18:42:31Z

@josephsavona Yeah I was kinda torn about it but I was thinking that there should be no case ever where the cache size would change in between renders in prod, so it's better to error early. Alternatively (as you also pointed out in (b)) we can always reset the cache if the size changes in any environment, which would then eliminate the dev/prod divergence

josephsavona · 2024-08-13T02:15:30Z

Per offline discussion let's go with resetting whenever the size changes. Seems like we're agreed that the ideal way to do this is for React to get a signal that a particular component fast refreshed and to reset the cache only then. But let's save that for a follow-up.

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. However, for consistency we continue to reset the cache as well. ghstack-source-id: b295a5d Pull Request resolved: #30663

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. However, for consistency we continue to reset the cache as well. ghstack-source-id: 7f343a7 Pull Request resolved: #30663

[ghstack-poisoned]

During development when adding or removing code, it is common for the cache size to vary between refreshes. Rather than warn like before, let's simply and safely reset the cache completely whenever its size changes between renders. In practice, in non-development environments full invalidation should never happen since the only consumer of uMC is compiled code – which always emits a static call to uMC with a fixed size. However, for consistency we continue to reset the cache as well. ghstack-source-id: 440a899 Pull Request resolved: #30663

poteto · 2024-08-13T14:27:39Z

@josephsavona updated

[ghstack-poisoned]

gaearon · 2024-08-14T12:15:15Z

Why is it not sufficient to always throw away the cache on hot reload? Unless I’m missing something, that’s what we do for useMemo.

poteto · 2024-08-14T14:44:48Z

@gaearon that's #30677

[ghstack-poisoned]

gaearon

I think #30700 should take care of this, assuming the special case is only needed for Fast Refresh.

poteto · 2024-08-14T21:39:50Z

Closing in favor of #30700

Stacked on #30662. Alternative to #30663 and #30677. During a Fast Refresh, we always want to evict the memo cache, same as we do with normal `useMemo`. The mechanism used by `useMemo` and other Hooks is this module-level variable: https://github.com/facebook/react/blob/fca5d655d78917400a2722287351c20938166669/packages/react-reconciler/src/ReactFiberHooks.js#L304-L307 which has DEV-only behavior as if the dependencies are always different: https://github.com/facebook/react/blob/fca5d655d78917400a2722287351c20938166669/packages/react-reconciler/src/ReactFiberHooks.js#L451-L460 The `useMemoCache` Hook doesn't use a dependency array but conceptually I think we want the same behavior. ## Test Plan The test passes. --------- Co-authored-by: Lauren Tan <poteto@users.noreply.github.com>

Stacked on #30662. Alternative to #30663 and #30677. During a Fast Refresh, we always want to evict the memo cache, same as we do with normal `useMemo`. The mechanism used by `useMemo` and other Hooks is this module-level variable: https://github.com/facebook/react/blob/fca5d655d78917400a2722287351c20938166669/packages/react-reconciler/src/ReactFiberHooks.js#L304-L307 which has DEV-only behavior as if the dependencies are always different: https://github.com/facebook/react/blob/fca5d655d78917400a2722287351c20938166669/packages/react-reconciler/src/ReactFiberHooks.js#L451-L460 The `useMemoCache` Hook doesn't use a dependency array but conceptually I think we want the same behavior. ## Test Plan The test passes. --------- Co-authored-by: Lauren Tan <poteto@users.noreply.github.com> DiffTrain build for [7e8a06c](7e8a06c)

Stacked on #30662. Alternative to #30663 and #30677. During a Fast Refresh, we always want to evict the memo cache, same as we do with normal `useMemo`. The mechanism used by `useMemo` and other Hooks is this module-level variable: https://github.com/facebook/react/blob/fca5d655d78917400a2722287351c20938166669/packages/react-reconciler/src/ReactFiberHooks.js#L304-L307 which has DEV-only behavior as if the dependencies are always different: https://github.com/facebook/react/blob/fca5d655d78917400a2722287351c20938166669/packages/react-reconciler/src/ReactFiberHooks.js#L451-L460 The `useMemoCache` Hook doesn't use a dependency array but conceptually I think we want the same behavior. ## Test Plan The test passes. --------- Co-authored-by: Lauren Tan <poteto@users.noreply.github.com> DiffTrain build for commit 7e8a06c.

Update

e0a5101

[ghstack-poisoned]

poteto mentioned this pull request Aug 12, 2024

[fresh] Add failing test for useMemoCache reset case #30662

Merged

facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Aug 12, 2024

poteto commented Aug 12, 2024

View reviewed changes

vercel bot deployed to Preview August 12, 2024 15:44 View deployment

Update

0b71a9a

[ghstack-poisoned]

vercel bot deployed to Preview August 12, 2024 15:48 View deployment

Update

db60bff

[ghstack-poisoned]

Update

89b4e7b

[ghstack-poisoned]

poteto requested a review from josephsavona August 12, 2024 15:52

poteto marked this pull request as ready for review August 12, 2024 15:52

vercel bot deployed to Preview August 12, 2024 15:53 View deployment

Update

e0a9ed8

[ghstack-poisoned]

vercel bot deployed to Preview August 12, 2024 15:58 View deployment

josephsavona reviewed Aug 12, 2024

View reviewed changes

Update

61e1199

[ghstack-poisoned]

vercel bot deployed to Preview August 13, 2024 14:14 View deployment

Update

a4d6334

[ghstack-poisoned]

Update

0bf7a11

[ghstack-poisoned]

vercel bot deployed to Preview August 13, 2024 14:29 View deployment

Update

fc86687

[ghstack-poisoned]

poteto mentioned this pull request Aug 13, 2024

[fresh] Reset useMemoCache in response to a FastRefresh run #30677

Closed

vercel bot deployed to Preview August 13, 2024 18:56 View deployment

poteto added 2 commits August 14, 2024 14:44

Update

3f49e49

[ghstack-poisoned]

Update

237ebef

[ghstack-poisoned]

vercel bot deployed to Preview August 14, 2024 18:54 View deployment

gaearon mentioned this pull request Aug 14, 2024

[Fresh] Always reset useMemoCache on Fast Refresh #30700

Merged

gaearon requested changes Aug 14, 2024

View reviewed changes

poteto closed this Aug 14, 2024

poteto deleted the gh/poteto/2/head branch October 7, 2024 22:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[fresh] Reset useMemoCache when size changes #30663

[fresh] Reset useMemoCache when size changes #30663

Uh oh!

poteto commented Aug 12, 2024 •

edited

Loading

Uh oh!

vercel bot commented Aug 12, 2024 •

edited

Loading

Uh oh!

react-sizebot commented Aug 12, 2024 •

edited

Loading

Uh oh!

poteto Aug 12, 2024 •

edited

Loading

Uh oh!

kassens Aug 12, 2024

Uh oh!

sebmarkbage Aug 12, 2024

Uh oh!

gaearon Aug 14, 2024

Uh oh!

gaearon Aug 14, 2024

Uh oh!

josephsavona left a comment

Uh oh!

poteto commented Aug 12, 2024 •

edited

Loading

Uh oh!

josephsavona commented Aug 13, 2024

Uh oh!

poteto commented Aug 13, 2024

Uh oh!

gaearon commented Aug 14, 2024

Uh oh!

poteto commented Aug 14, 2024

Uh oh!

gaearon left a comment

Uh oh!

poteto commented Aug 14, 2024

Uh oh!

Uh oh!

[fresh] Reset useMemoCache when size changes #30663

[fresh] Reset useMemoCache when size changes #30663

Uh oh!

Conversation

poteto commented Aug 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vercel bot commented Aug 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

react-sizebot commented Aug 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Critical size changes

Significant size changes

Uh oh!

poteto Aug 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kassens Aug 12, 2024

Choose a reason for hiding this comment

Uh oh!

sebmarkbage Aug 12, 2024

Choose a reason for hiding this comment

Uh oh!

gaearon Aug 14, 2024

Choose a reason for hiding this comment

Uh oh!

gaearon Aug 14, 2024

Choose a reason for hiding this comment

Uh oh!

josephsavona left a comment

Choose a reason for hiding this comment

Uh oh!

poteto commented Aug 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

josephsavona commented Aug 13, 2024

Uh oh!

poteto commented Aug 13, 2024

Uh oh!

gaearon commented Aug 14, 2024

Uh oh!

poteto commented Aug 14, 2024

Uh oh!

gaearon left a comment

Choose a reason for hiding this comment

Uh oh!

poteto commented Aug 14, 2024

Uh oh!

Uh oh!

poteto commented Aug 12, 2024 •

edited

Loading

vercel bot commented Aug 12, 2024 •

edited

Loading

react-sizebot commented Aug 12, 2024 •

edited

Loading

poteto Aug 12, 2024 •

edited

Loading

poteto commented Aug 12, 2024 •

edited

Loading