Data: deprecate the getIsResolving selector #59679
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
jsnajdr
added
[Type] Enhancement
|
Size Change: +64 B (0%) Total Size: 1.71 MB
ℹ️ View Unchanged
|
ntsekouras
reviewed
Mar 7, 2024
|
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. |
ntsekouras
reviewed
Mar 7, 2024
tyxla
approved these changes
Mar 7, 2024
| const resolutionState = getResolutionState( state, selectorName, args ); | ||
| deprecated( 'wp.data.select( store ).getIsResolving', { | ||
| since: '6.6', | ||
| alternative: 'wp.data.select( store ).getResolutionState', |
There was a problem hiding this comment.
Should we also add a version: 6.8 or similar to the deprecation warning to suggest removing in a future WP version?
There was a problem hiding this comment.
Yes, it seems that getIsResolved could indeed be removed in future. A wpdirectory.net search shows that the selector is not used by plugins -- all the search results that I checked are coming from bundled instances of @wordpress/data itself.
jsnajdr
force-pushed
the
deprecate/get-is-resolving
branch
from
4001883 to
eba3c20
Compare
jsnajdr
force-pushed
the
deprecate/get-is-resolving
branch
from
eba3c20 to
e55182b
Compare
bph
added
[Type] Code Quality
carstingaxion
pushed a commit
to carstingaxion/gutenberg
that referenced
this pull request
Mar 27, 2024
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.
This PR is inspired in discussion in #59437 (comment)
The
getIsResolvingmeta-selector should be deprecated. It returns a weirdundefined | booleanvalue and it was introduced in #6600, six years ago, when the "raw" value in the store was of this type. At that time it made sense as the "raw getter". Nowadays the raw value is a more complex object returned bygetResolutionStatus.Users should use the
isResolvingselector instead, which returns a cleantrue/falseboolean.I'm migrating all Gutenberg usages of
getIsResolving(there are not that many) toisResolving.I'm also updating how the resolution status values are computed in
enrichSelectorsused byuseQuerySelectanduseEntityRecords. The existing code "reverse engineers" the status value from theisResolvingandhasResolvedvalues, but it can just straightforwardly calculate it fromgetResolutionStatus, simply mapping strings to an enum.Last, the PR is adding
hasStartedfield to theuseQuerySelectreturn value. Curiously, that value is declared in the type,QuerySelectResponse, but not actually returned.