-
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
Formalise deprecation of useEntityId
hook in favour of useEntityProviderId
#39681
Conversation
Pinging @draganescu who is leading the release of |
since: '6.0', | ||
alternative: 'the @wordpress/core-data useEntityProviderId() hook', | ||
} ); | ||
return useEntityProviderId( kind, type ); |
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'm curious why we decided to change the name here. For me "Provider" is just an implementation detail (React context) and what we really do with this hook is to retrieve the "entityId". so I think the old naming is better 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.
I don't have the context. Adam or Greg might know but they are unavailable.
Would you prefer we just renamed back to useEntityId()
? That would avoid the whole deprecation thing.
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.
For now we can move on with the deprecation notice as the other PR has been through longer discussions and we may miss some context.
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 disagree, I think we should just restore the old name 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.
I didn't find any thing clarifying the reasoning for this particular hook name change and since it's a breaking change, I'd rather revert instead of adding a deprecation and then later a deprecation that deprecate the deprecation :)
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 does seem to be the only instance where the "provider" term is included in the public API (apart from the actual Provider itself). I can't see renaming back being a huge problem.
Probably safest to rename back and then ask Adam, Dennis and Greg to re-review when they are available. If they really want to rename it they can always submit a followup with the appropriate rationale for the next release.
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.
OK here's the alternative. Please let me know which route we'd like to take.
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.
@youknowriad @getdave @draganescu it was a part of #39349. Why? The name useEntityId()
is slightly off semantically. An Entity
is a higher-level idea that refers to Comments and Posts and such. An entity is not a data container, though, and does not store a numerical ID. That would be an Entity Record
. In this case, though, the ID does not even come from the record but from the Entity Provider – hence the name change to clarify that.
I missed the fact that this function was a part of the public API, though. I specifically wanted to avoid any public-facing changes and even made a note about that. Thank you for the prompt reaction and a fix 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.
I agree that "entity" is not the right semantic here but it's a bit better than "provider" for me. Ideally yet it should be useEntityRecordId
the provider should be EntityRecordProvider
. We can make these changes (and deprecate the old ones if deemed necessary)
Size Change: +60 B (0%) Total Size: 1.21 MB
ℹ️ View Unchanged
|
Closing in favour of #39683 |
What?
Alternative to #39683
This PR fully handles the formal deprecation of
useEntityId
in favour ofuseEntityProviderId
. This was undertaken in #39349 but that PR didn't handle the deprecation process.Why?
This hook is part of the public API of
@wordpress/core-data
but it has been removed in favour ofuseEntityProviderId
without the formal deprecation process.This was caught as part of a fix to the Navigation block which broke when the hook was removed.
How?
This PR
@wordpress/core-data
deprecation()
call.I believe the change of arg signature from
type
toname
is purely nomenclature, but it would be worth validating I have understood this correctly.Testing Instructions
Start empty
Advanced
panel of block's Inspector controlstrunk
it crashes)Screenshots or screencast