-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Core Data: Bring back support for nested _fields
values
#25083
Conversation
Size Change: +19 B (0%) Total Size: 1.2 MB
ℹ️ View Unchanged
|
@@ -76,12 +77,12 @@ function getQueriedItemsUncached( state, query ) { | |||
// This accounts for the fact that queried items are stored by | |||
// stable key without an associated fields query. Other requests | |||
// may have included fewer fields properties. | |||
const field = fields[ f ]; | |||
if ( ! item.hasOwnProperty( field ) ) { | |||
const field = fields[ f ].split( '.' ); |
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 this value is left as a string, it matches an undefined value in the state— in my testing I had both meta: { key: 'value' }
and 'meta.key': undefined
on item
, and get
matches the string key first, returning undefined. I'm not sure where that other key comes from, but preventing that would be a better fix for this workaround.
Just noting that before #25078 doing this would create subtle bugs where some components could receive "incomplete" entities data. Basically |
I tested the PR and it fixed the problem for me 👍🏻 |
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.
Thanks
Description
Fixes #25078 — The change to
getEntityRecords
's use of _fields has broken nested meta field requests. In the API, you can pass nested fields for meta, ex:wp-json/wp/v2/posts?_fields=title,meta.demo,id
, and this used to work for the getEntityRecords request.It seems the change in #19498 introduced this:
gutenberg/packages/core-data/src/queried-data/selectors.js
Lines 80 to 82 in 8ba0a42
Which is returning null, because it's testing for
item['meta.key']
, rather thanitem.meta.key
. This PR switches to using the lodash functionshas
,get
, andset
, which support string keys like that. I've seen some moves away from lodash, but it seems like the most straightforward fix here.How has this been tested?
There's a new test case introduced in
packages/core-data/src/queried-data/test/selectors.js
which catches this case.You can also test with the code snippet in #25078
Types of changes
Bug fix (non-breaking change which fixes an issue)