useSelect: only invalidate on subscribe if store changed #57108
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: +646 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 211dbd3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7226521084
|
ellatrix
changed the title
jsnajdr
reviewed
Dec 15, 2023
| const subscribe = ( _listener ) => { | ||
| cleanup(); | ||
| return subscriber.subscribe( _listener ); | ||
| }; |
There was a problem hiding this comment.
If the returned subscribe function is never called, the subscription you’re newly creating will leak, if will be there forever and never cleaned up.
There was a problem hiding this comment.
Will fix in the next commit
There was a problem hiding this comment.
@jsnajdr Ok, I changed it to avoid subscribing and simply compare the store states with those on mount. If all the states are equal, then lastMapResultValid can remain true.
ellatrix
commented
Dec 15, 2023
| storeStatesOnMount[ index ] === | ||
| // To do: figure out why it's sometimes not available in | ||
| // unit tests. | ||
| registry.stores[ storeName ]?.store?.getState?.() |
There was a problem hiding this comment.
@jsnajdr @youknowriad Any idea why this is not available in some unit tests? Something about custom generic stores? Is there a better way to may store names to their state?
There was a problem hiding this comment.
Yes, custom generic stores. The things in registry.stores have an interface that doesn't guarantee a .store property, only the "mainstream" Redux stores have that. The rest have only the published selectors.
I'm curious if this state comparison is still a performance optimization, as it's a completely different approach than the original subscribe one.
There was a problem hiding this comment.
It should be, the graph looks the same as the other optimisation
There was a problem hiding this comment.
Getting -6.75% for first block load in this run.
There was a problem hiding this comment.
I guess if there's no interface, we can always return false for now (previous behaviour). But strange that there's no way to get the state.
There was a problem hiding this comment.
I'm thinking we could add an optional getSnapshot or getStableReference to the interface to address this use-case.
There was a problem hiding this comment.
Should we try that separately?
There was a problem hiding this comment.
Second run after the rewrite is 6.6% for first block load
There was a problem hiding this comment.
I'm thinking we could add an optional
getSnapshotorgetStableReferenceto the interface
Yes, and to prevent misuse to read private-ish data, return an empty object {} memoized/keyed in weakmap by the real state object.
jsnajdr
reviewed
Dec 15, 2023
| activeStores.length === storeStatesOnMount.length && | ||
| activeStores.every( | ||
| ( storeName, index ) => | ||
| storeStatesOnMount[ index ] === |
There was a problem hiding this comment.
The subscribe function could be called multiple times to obtain multiple subscriptions. React probably never does it, but it's a reasonable operation anyway. Here, the second subscribe call will dereference a null object and crash.
By the way, what if storeStatesOnMount was an object keyed by store name? Seems better than array to me.
There was a problem hiding this comment.
Yes, that's true, a Map is cleaner and also solves the other issue.
jsnajdr
reviewed
Dec 15, 2023
| storeStatesOnMount[ index ] === | ||
| // To do: figure out why it's sometimes not available in | ||
| // unit tests. | ||
| registry.stores[ storeName ]?.store?.getState?.() |
There was a problem hiding this comment.
I'm thinking we could add an optional
getSnapshotorgetStableReferenceto the interface
Yes, and to prevent misuse to read private-ish data, return an empty object {} memoized/keyed in weakmap by the real state object.
youknowriad
approved these changes
Dec 15, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Currently we invalidate the selector mapping result whenever React subscribes to the store. This is to make sure the value is fresh because it might have changed between the first time we update the value and when React subscribes.
Instead, temporarily listen for store changes and only invalidate the result if it changed (which shouldn't happen often).
Why?
This prevents all the
useSelectresult from being calculated twice on load/mount.First run load first block -6.75% (after the rewrite)
Second run -6.6%
The block marked red is now gone:
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast