-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getEntityRecords: batch actions #60591
Conversation
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
packages/core-data/src/resolvers.js
Outdated
].join(), | ||
}; | ||
( { dispatch, registry } ) => { | ||
registry.batch( async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: does the resolver callback need to remain async? Does that mean batch needs to become async?
Question: could we build in batching resolver callbacks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cc @youknowriad and @jsnajdr cause I don't really know what I'm doing here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not supported. This comment is relevant #60495 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think batching async stuff make sense. You want to UI and meta selectors (isResolving) to actually update to show spinners... when requests are ongoing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I understand now. I changed the PR to only batch the non async actions now.
Size Change: -3 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
type: 'FINISH_RESOLUTIONS', | ||
selectorName: 'getEntityRecord', | ||
args: resolutionsArgs, | ||
} ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the start and finish actions are batched, then there's no point dispatching START_RESOLUTIONS
. The state will be overwritten by FINISH_RESOLUTIONS
, and no listener will see the state between start and finish because listeners are not called during a batch.
If some listener is observing the resolution state and expects to see the full cycle, undefined
-> resolving
-> finished
, it might get suprised that it won't ever see resolving
. It will go directly to finished
. Not sure how much breaking this is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it probably doesn't really make sense to call "start" in this case, we just want to make these as resolved to avoid requests.
Co-authored-by: ellatrix <ellatrix@git.wordpress.org> Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
} finally { | ||
dispatch.__unstableReleaseStoreLock( lock ); | ||
} ); | ||
} catch ( e ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should switch this back to try...finally
. The catching error here means it won't be passed to the resolution state (getResolutionError
) and might affect the error state for useSuspenseSelect
. (#37261).
But that means we won't be able to batch dispatch.__unstableReleaseStoreLock
.
gutenberg/packages/data/src/redux-store/index.js
Lines 533 to 535 in 0d1943c
if ( selectors.hasResolutionFailed( selectorName, args ) ) { | |
throw selectors.getResolutionError( selectorName, args ); | |
} |
What?
getEntityRecords
currently dispatches quite a few actions that are not batched.Why?
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast