Allow making context specific requests using the data module #32961
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
youknowriad
added
Framework
|
(Don't review this just yet, I have some local changes changing the approach entirely but I'm having trouble pushing them due to internet issues, I'll update here once I'm done) |
|
Size Change: +1.76 kB (0%) Total Size: 1.04 MB
ℹ️ View Unchanged
|
youknowriad
changed the title
youknowriad
force-pushed
the
add/allow-alternative-context-data-package
branch
from
8b29ace
to
b284577
Compare
|
Ok I managed to push the changes, this is ready to review. |
ntsekouras
reviewed
Jun 25, 2021
ntsekouras
reviewed
Jun 25, 2021
ntsekouras
reviewed
Jun 25, 2021
Co-authored-by: Nik Tsekouras <ntsekouras@outlook.com>
youknowriad
added
the
Backport to WP 6.7 Beta/RC
|
I'm adding this to the backport list to be able to use it to fix the permissions checks for the site blocks. |
ntsekouras
approved these changes
Jun 25, 2021
jsnajdr
reviewed
Jun 25, 2021
There was a problem hiding this comment.
The packages/core-data/src/reducer reducer also handles the RECEIVE_ITEMS action in the edits part. Should it also check the action.context field and ignore responses that don't have the edit context?
The receiveEntityRecords and removeItems have an invalidateCache flag. The getEntityRecords.shouldInvalidate handler that looks at this flag should correctly and carefully choose the queries to invalidate: only the context-specific one for RECEIVE_ITEMS, and all contexts for REMOVE_ITEMS.
| @@ -41,6 +41,7 @@ export function getQueryParts( query ) { | |||
| perPage: 10, | |||
| fields: null, | |||
| include: null, | |||
| context: 'default', | |||
There was a problem hiding this comment.
If the context query param is omitted, the default value is view.
There was a problem hiding this comment.
no, we do enforce "edit" context in the API requests, even if the context is "view" by default for the server, that's why I opted on a new "default"/"empty" context in the frontend. Backward compatibility.
There was a problem hiding this comment.
Does that mean that calling getQueriedItems without context will issue an API request with ?context=edit query param and will store the result under the state[ 'default' ] key?
And that getQueriedItems( state, { context: 'edit' } ) will issue a request with the same ?context=edit query param but this time will store the result as state[ 'edit' ]?
There was a problem hiding this comment.
Does that mean that calling getQueriedItems without context will issue an API request with ?context=edit query param and will store the result under the state[ 'default' ] key?
In most entities yes, but entities can define another set of default REST API parameters.
I agree it's not ideal that edit is different than default in this cases, but solving it properly would have required a small change in the entities API (explicitly define a default context instead of relying on a more global baseURLParams). I think it's something we can try but I thought it was not important for v1 of this.
There was a problem hiding this comment.
I agree that it's not terribly important. I mostly wanted to confirm that this little flaw is really there, and that it's not just my misunderstanding.
I think creating a record in a one context, should invalidate queries in all contexts |
youknowriad
removed
the
Backport to WP 6.7 Beta/RC
youknowriad
added a commit
that referenced
this pull request
Jun 25, 2021
Co-authored-by: Nik Tsekouras <ntsekouras@outlook.com>
youknowriad
added a commit
that referenced
this pull request
Jun 25, 2021
Co-authored-by: Nik Tsekouras <ntsekouras@outlook.com>
This was referenced Jul 20, 2021
7 tasks
This was referenced Oct 5, 2021
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.
closes #11643
We've been struggling with context specific data request for a long time in Gutenberg. This is due to the fact that the data module had always had a single representation of what an entity record could look like.
In this PR, I'm exploring allowing context specific requests. I'm doing so by separating the results from requests of different context, it's like considering these as different entities entirely.
Hopefully, this will allow us to get rid of all the adhoc
apiFetchusage across the code base.