-
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
Use consistent terminology across @wordpress/core-data #39349
Conversation
…opriate in the given context
* @param {number} props.id The entity ID. | ||
* @param {*} props.children The children to wrap. | ||
* | ||
* @return {Object} The provided children, wrapped with | ||
* the entity's context provider. | ||
*/ | ||
export default function EntityProvider( { kind, type, id, children } ) { | ||
const Provider = getEntity( kind, type ).context.Provider; | ||
export default function EntityProvider( { kind, type: name, id, children } ) { |
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.
It would be nice to refactor it at one point, but that's a part of the public API and beyond the scope of this PR.
Size Change: -48 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
I think you need to run I like the idea to unify the terminology. We did a similar round of changes in the |
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.
Apart from any failing tests I'm all for this. The code is considerably easier to follow with consistent terminology.
@@ -299,13 +299,13 @@ export const editEntityRecord = ( | |||
edits, | |||
options = {} | |||
) => ( { select, dispatch } ) => { | |||
const entity = select.getEntity( kind, name ); | |||
if ( ! entity ) { | |||
const entityConfig = select.getEntityConfig( kind, name ); |
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.
my goodness this line's change alone makes this PR worthwhile.
const entities = await dispatch( getKindEntities( kind ) ); | ||
const entity = find( entities, { kind, name } ); | ||
const configs = await dispatch( getOrLoadEntitiesConfig( kind ) ); | ||
const entityConfig = find( configs, { kind, name } ); |
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 wonder if there's a reason we dispatch this action here but rely on the getEntityConfig
selector for editEntityRecord
, and dispatch again on saveEntityRecord
when deleting and saving we will try and fetch more entity configs if we can't find the given one, but on edit
we give up immediately.
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.
My guess is that by the time we edit an entity record, it must have been resolved, which means that the loading already happened in a different code path. Definitely confusing, though. It would be easier to read if we relied on getOrLoad
in editEntityRecord
too, even if only for consistency. Let's save it for another PR.
since: '6.0', | ||
alternative: "wp.data.select( 'core' ).getEntitiesConfig()", | ||
} ); | ||
return getEntitiesConfig( state, kind ); |
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.
these deprecations are so good. we have too many functions named different things that return the same data
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 did some testing on this and would have expected things to collapse if there had been a bug. Specifically I tested FSE and the loading of page templates to run through the kind-loading code.
Please defer to your own judgement and external review; I'm not fully confident in my understanding of the core-data
subsystem.
*/ | ||
export function useEntityId( kind, type ) { | ||
return useContext( getEntity( kind, type ).context ); | ||
export function useEntityProviderId( kind, name ) { |
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.
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.
Good catch. Yup I can confirm this broke the Navigation block so it will have impact further down the chain.
@adamziel is AFK so I will look into restoring the original and adding a deprecation notice to point to useEntityProviderId
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.
Follow up here #39681
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.
Also an alternative approach here #39683
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.
Great catch @talldan, I must have missed the fact this was a public API. Thanks for the prompt reaction and a fix!
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.
Linking to the related discussion for posterity.
What?
This PR unifies the language used in core-data, leaving only one term for each concept. The most prominent changes are:
Entity loader
replacedkind
,kind config
, andentity
Entity config
replacedentity
andkind entity
(in actions, selectors, and resolvers)Entity context
replacedentity
(in the entity provider)Entity name
replacedentity name
andentity type
(in the entity provider)state.records
replacedstate.data
Other than two deprecations in
selectors.js
, this PR aims to keep the public API of the core-data package the same. Every consumer of this package should continue to work in the exact same way.Why?
I walked through that code with @dmsnell a few days ago, and we both got super confused by all the different terms imprecisely referring sometimes to the same ideas, and sometimes to completely different ones. My intention in this PR is to make the immersion easier.
Testing Instructions
cc @gziolo @youknowriad @ellatrix @noisysocks @talldan @getdave @kevin940726 @Mamaduka