Framework: Deprecate uid in favor of clientId#7990
Conversation
youknowriad
left a comment
There was a problem hiding this comment.
I personally prefer the concisness of uid even if clientId is more descriptive but noting that client can have several meanings :)
Anyway, I don't care too much and this PR is very hard to review/upgrade. I kind of trust our tests for it, so I'm approving to avoid staling PR. (I took a look but it's not easy to validate all the implications)
gziolo
left a comment
There was a problem hiding this comment.
I also skimmed those changes. We have deprecations for both updated props in case of components and for updated selectors. We should still include some notes in the deprecation document.
There was a problem hiding this comment.
This is a really cool usage of createHigherOrderComponent 👍
4b1a490 to
40b988c
Compare
|
Added a broad note to the
Rebased and did another pass of instances of |

Related: #7669
This pull request seeks to deprecate all references to "UID" in the codebase with equivalent "Client ID" naming. This change is being made in an effort to promote consistency on abbreviation capitalization, where, for example, previous selectors...
getAdjacentBlockUidgetBlockRootUID...become:
getAdjacentBlockClientIdgetBlockRootClientIdObserving the changes, you should see a number of other inconsistencies having been addressed here, including references to a block's
idwhereuidis intended.Note: This is a massive pull request, which is prone to becoming stale very quickly. I'd urge that this be acted upon soon to avoid issues with merge conflicts.
Implementation notes:
This does include deprecations, not only for the selectors, but also covering components which we expose on
wp.editorwhich accept some prop referencing a "uid". This is achieved through a new (and temporary)withDeprecatedUniqueIdhigher-order component.Testing instructions:
Ensure all forms of automated tests pass.
Verify there are no lingering references to UID in the entire codebase, aside from those necessary for temporary compatibility until total removal.
Ensure that deprecations work effectively. Here's a test block as an example, whose
editfunction depends on both theidprop being passed and theBlockTitlecomponent accepting auidprop: