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.
What?
This PR adds Entity configuration types to
core-data/src/entities.ts
.It is an alternative to #40024. See also #39025, a mega branch that proposes TypeScript signatures for all
@wordpress/core-data
selectors.Why?
Consider the
getEntityRecord
selector:gutenberg/packages/core-data/src/selectors.js
Lines 157 to 171 in 395aea4
Different entity kinds, like
root
,postType
,taxonomy
, are associated with different entity names. For example,kind: root, name: plugin
is a valid combination, butkind: postType, name: plugin
is not. Other valid combinations are configured in theentities.ts
file via a JavaScript object.An ideal
getEntityRecord
function signature would only accept valid combinations, then require thekey
to be eithernumber
or astring
, and return the list of corresponding entity records.Again, ideally, there would only be a single source of truth for all the information. That's exactly what this PR enables by introducing the Entity types:
That
PluginEntity
type can then be reused to build thegetEntityRecord
signature.Why write the kind and name twice?
This is a trade-off. I've spent hours exploring the available options with @dmsnell and we concluded that it's only possibl to either:
const config =
and miss out on autocompletion, config type validation, and require usingas const
. Reuse the JS entities configuration in the TypeScript type system #40024 explored thatconst config =
and have all of the above, but at the cost of using super complex type plumbing. This TS playground explores thatThis PR implements the latter approach.
Why have a new config type?
Good question! It's needed because entity configuration comes from three different sources:
entities.ts
kind=postType
isedit
as seen inloadPostTypeEntities
A somewhat eccentric metaphor would be picturing it as a MySQL query that joins three tables:
A common format like the
PluginEntity
makes reasoning about all these data sources much easier down the road, e.g. it enables the following succinct formulation of the Kind type:Test plan
Confirm the checks are green and that no entity configuration got changed when I split the large array into atomic declarations. The changes here should only affect the type system so there is nothing to test in the browser.
cc @dmsnell @jsnajdr @youknowriad @sarayourfriend @getdave @draganescu @scruffian