[ntsekouras]

What?

Part of: #83368 (Stage 1, item 4 of the merge plan)

This PR adds the client side of reading the fields from the server, without any consumer yet.

core-data gets a selector (getFieldsConfig) to fetch the fields from the REST API, and the new bundled package @wordpress/fields-loader builds on it with useFields and loadFields: they request the fields, import the script modules registered along with them and merge their JS parts into the fields, in the order the server lists them.

The selector is public because the package is bundled, so it can't unlock a private one(and on an older WP it's simply missing, which the package reports as an error instead of throwing). The package is deliberately not a wp.* script, since plugins need to bundle it to fall back when the site doesn't have the Fields API yet.

Notes

The README describes the wp-editor attach point from #84078. There's a thread about a lighter one (#83368 (comment)), but it doesn't affect the code here: the loader imports whatever modules the server lists, wherever they're attached, and it doesn't know about the import map.

If the attach point changes, the README needs an update on how a plugin screen gets the modules and which globals they can use.

Testing Instructions

1. Nothing uses the new code yet, so there are no UI changes. Everything should work as before.

Use of AI Tools

Generated with Fable 5.1 and adjusted/reviewed manually.

[github-actions]

🤖 PR meta 🤖

🎉 Props

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

📦 Bundle size

Size Change: +119 B (0%)

Total Size: 8.38 MB

📦 View Changed

Filename	Size	Change
build/scripts/core-data/index.min.js	79 kB	+119 B (+0.15%)

_{b306320 Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	669961b	trunk	% Change
timeToFirstByte	57 ms +10.26% -2.63%	59.1 ms +9.9% -5.25%	-3.55%
largestContentfulPaint	98 ms +4.08% -6.12%	100 ms +4% -8%	-2%
lcpMinusTtfb	36.65 ms +17.33% -6.41%	36.45 ms +22.22% -5.08%	0.55%
wpBeforeTemplate	28.53 ms +12.97% -1.09%	29.1 ms +16.43% -2.47%	-1.96%
wpTemplate	24.41 ms +6.1% -3.15%	25.28 ms +5.85% -5.14%	-3.44%
wpTotal	53.32 ms +10.6% -2.68%	55.2 ms +10.54% -4.91%	-3.41%
wpMemoryUsage	7.67 MB +0% -0%	7.64 MB +0% -0%	0.45%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	669961b	trunk	% Change
timeToFirstByte	47.9 ms +9.6% -1.04%	48 ms +3.13% -1.35%	-0.21%
largestContentfulPaint	104 ms +3.85% -0%	104 ms +0% -1.92%	0%
lcpMinusTtfb	56.1 ms +0.62% -4.1%	55.5 ms +2.43% -3.6%	1.08%
wpBeforeTemplate	26.55 ms +6.78% -1.32%	26.43 ms +4.24% -1.17%	0.45%
wpTemplate	18.27 ms +5.2% -1.26%	18.59 ms +0.75% -2.47%	-1.72%
wpTotal	44.63 ms +9.68% -0.72%	44.87 ms +3.37% -1.4%	-0.53%
wpMemoryUsage	6.30 MB +0% -0%	6.25 MB +0% -0%	0.7%
wpDbQueries	14 +0% -0%	14 +0% -0%	0%

media-processing

Metric	669961b	trunk	% Change
mediaProcessingJpeg	404.38 ms +1.64% -1.64%	400.56 ms +0.6% -1.29%	0.95%
mediaProcessingAvif	6077.24 ms +0.29% -0.15%	6032.63 ms +0.22% -0.09%	0.74%
mediaProcessingJpegToAvif	4184.89 ms +0.14% -0.3%	4180.18 ms +0.22% -0.06%	0.11%

media-upload

Metric	669961b	trunk	% Change
jpegUploadProcessing	1690.96 ms +16.14% -15.69%	1413.31 ms +0.69% -0.5%	19.65%
pngUploadProcessing	195.24 ms +22.8% -4.82%	207.63 ms +13.16% -17.4%	-5.97%
largeJpegUploadProcessing	1417.67 ms +0.59% -1.01%	1416.19 ms +0.45% -0.74%	0.1%
multipleImageUploadProcessing	1568.74 ms +2.58% -1.69%	1578 ms +8.76% -0.23%	-0.59%

post-editor

Metric	669961b	trunk	% Change
serverResponse	345.72 ms +5.15% -5.73%	334.81 ms +4.59% -2.71%	3.26%
firstPaint	217.58 ms +66.23% -25.23%	222.77 ms +13.1% -11.76%	-2.33%
domContentLoaded	834.87 ms +0.97% -2.48%	840.4 ms +2.05% -1.48%	-0.66%
loaded	835.72 ms +0.98% -2.45%	841.42 ms +2.04% -1.49%	-0.68%
firstContentfulPaint	361.2 ms +2.18% -2.03%	366.26 ms +2.53% -3.4%	-1.38%
firstBlock	2406.41 ms +3.03% -1.05%	2428.74 ms +0.68% -0.76%	-0.92%
type	15.75 ms +1.14% -1.9%	15.84 ms +1.83% -3.03%	-0.57%
typeWithoutInspector	15.86 ms +4.1% -2.08%	14.71 ms +8.09% -0.48%	7.82%
typeWithTopToolbar	20 ms +4.95% -1.9%	20.25 ms +2.12% -5.78%	-1.23%
typeContainer	7.6 ms +1.32% -3.03%	7.7 ms +5.84% -7.14%	-1.3%
focus	92.97 ms +3.98% -5.82%	88.84 ms +4.69% -4.64%	4.65%
firstFocus	189.17 ms +0% -0%	180 ms +0% -0%	5.09%
selectAll	363.5 ms +2.17% -2.59%	343.39 ms +2.89% -1.43%	5.86%
listViewOpen	60.83 ms +8.1% -5.95%	58.53 ms +7.71% -9.26%	3.93%
inserterOpen	34.47 ms +6.15% -4.9%	32.25 ms +9.36% -6.14%	6.88%
inserterHover	10.06 ms +7.95% -9.64%	9.66 ms +10.04% -5.07%	4.14%
inserterSearch	7.5 ms +5.07% -6.53%	7.6 ms +8.42% -3.68%	-1.32%
loadPatterns	519.72 ms +7% -3.14%	530.85 ms +1.38% -3.29%	-2.1%
wpTotal	336.96 ms +4.85% -5.84%	326.33 ms +4.8% -2.88%	3.26%
wpMemoryUsage	13.23 MB +0% -0%	13.20 MB +0% -0%	0.28%
wpDbQueries	54 +0% -0%	54 +0% -0%	0%

site-editor

Metric	669961b	trunk	% Change
serverResponse	250.83 ms +4.24% -4.86%	251.13 ms +2.28% -4.2%	-0.12%
firstPaint	181.65 ms +57.57% -18.5%	184.12 ms +17.29% -15.47%	-1.34%
domContentLoaded	716.83 ms +5.6% -1.65%	714.08 ms +1.6% -1.84%	0.39%
loaded	717.73 ms +5.69% -1.66%	714.95 ms +1.6% -1.84%	0.39%
firstContentfulPaint	306.38 ms +6.33% -3.14%	314.55 ms +3.86% -2.77%	-2.6%
firstBlock	2624.45 ms +3.38% -1.76%	2613.15 ms +1.17% -1.51%	0.43%
type	14.14 ms +3.89% -2.9%	12.99 ms +4.54% -1.54%	8.85%
navigate	78.52 ms +20.06% -1.64%	88.05 ms +5.21% -24.62%	-10.82%
loadPatterns	1023.61 ms +11.59% -11.43%	943.76 ms +18.55% -11.65%	8.46%
loadPages	944.94 ms +1.21% -0.8%	989.28 ms +4.36% -4.87%	-4.48%
wpTotal	244.31 ms +4.29% -4.92%	244.83 ms +2.26% -4.36%	-0.21%
wpMemoryUsage	12.27 MB +0% -0%	12.22 MB +0% -0%	0.4%
wpDbQueries	44 +0% -2.27%	44 +0% -2.27%	0%

_{b306320 Run}

[youknowriad]

Why do we need a fields-loader package? Why is this just not some actions/hooks on core-data?

[ntsekouras]

Why do we need a fields-loader package? Why is this just not some actions/hooks on core-data?

FWIW it mirrors what we do with @wordpress/views (eg. getFieldsConfig/getViewConfig, useFields/useViewConfig, etc..). The result has React components and DataViews Field types, so my take is that it feels odd to have it in core-data, which is more data oriented.

That said, is the concern the extra package? If yes, another possible home could be the views package.

[youknowriad]

The one thing that make "views" different is that views is also about preferences to persist the views, but it's close.

It is also very close to "CPTs" IMO as most fields are per entity which live in core-data. I think we should ask the question about what we do later when we have "blocks" are loaded in a similar way, or other things as well, think "admin pages" or any other "admin config" thing. Do we have a package for each of these "loaders" or are these part of "core-data" or another package that holds all of these together?

I'm a bit conflicted and undecided personally to be honest but I like how you put the selectors/resolvers in core-data and the package is just about the hooks. On the other side, we do have several useEntityProp hooks within core-data for instance.

So I guess we have both cases before, what I think we should do is make a decision and stick to it in the future (put it on agents.md or something) and potentially "unify" the approach (deprecations and such) over time.

cc @mcsf @oandregal

[youknowriad]

The one thing that I don't like though is the "loader" in the name. For me this should be just wordpress/fields if we stick with the package.

[mcsf]

I'm a bit conflicted and undecided personally to be honest but I like how you put the selectors/resolvers in core-data and the package is just about the hooks. On the other side, we do have several useEntityProp hooks within core-data for instance.

So I guess we have both cases before, what I think we should do is make a decision and stick to it in the future (put it on agents.md or something) and potentially "unify" the approach (deprecations and such) over time.

Given that most of the meat is in core-data, I think this looks good. Having the package bundled also gives us more flexibility (not as much as a private API, of course, but still), so it's not like we need to absolutely commit to a design pattern indefinitely. If, down the road, we get to lazy-loading blocks or admin pages as Riad suggests, I can see us organically coming up with a more general "loader-of-things" pattern that would render this current package obsolete. But, right now, YAGNI. :)

The one thing that I don't like though is the "loader" in the name

I don't like it either. Also, can we drop its fields-loader.ts‎ file and just have an index.ts?

[oandregal]

Going to close this one for now and regroup on the main prototype PR at #83368

After the past days of work we have landed the PHP fields API in trunk. It works for the screens that used usePostFields: site editor v1 (pages, templates, patterns, parts) as well as some experiments (DataForm Post Inspector, etc.). Client-side we haven't changed anything: those screens still use the existing private usePostFields hook that, under the hood, uses the useFields hook (bundled in the editor package for now). See #84700

This is less ambitious than what I pushed before: all screens that use DataViews/DataForm (stable, experimental, plus migrate some that were not using usePostFields) add also adding stable client site utils (useFields, loadFields). It's a compromise that allows us to make progress and take the time to make the right call about the client APIs, which didn't have as clear a path as initially understood.