Field API: rename text to string to align with block.json API

[oandregal]

Related #74102

What?

This PR renames the text field type to be string.

Why?

So it's aligned with block.json and the block-based controls we create going forward (PHP-only, block fields), don't need any type mapping — both block.json and the Field API use string.

How?

Before	After
Field type text	string

Not done:

• elements/getElements/useElements to enum/getEnum/useEnum.

While they reflect similar concerns, they have a different shape: enum is a list of values, elements is a list of options (object with value/label properties). If we were to do the rename, I argue we should support the block.json shape (a list of values) and we could remove this code.

Testing Instructions

• Smoke test stories: DataViews, DataForm, DataviewsPicker, Fields.
• Smoke test the site editor: Pages, Templates, Patterns.

[youknowriad]

This is a good thing for me. I wonder if we should keep a deprecation and back compat for a couple releases (like we used to do in early Gutenberg) as a courtesy for users, give them sometime to upgrade and leave the breaking change for a later release).

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

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: oandregal <oandregal@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@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.

[oandregal]

I relived this scaffolding PR I had and scoped it to only rename the text field type to string. See PR description.

[github-actions]

Flaky tests detected in 0ff122f.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22100155440
📝 Reported issues:

• [Flaky Test] As a user I expect my navigation to use the colors I selected for it #65427 in /test/e2e/specs/editor/blocks/navigation-colors.spec.js

[ntsekouras]

Nit: stringFields. Similarly for TextComponent.

[ntsekouras]

Should we update the Edit to string too?

[oandregal]

No, I don't think so. The controls aren't a 1:1 match with field types, and text/textarea remain a useful nomenclature in the domain of UI controls.

[ntsekouras]

This is an impactful change and I'd echo Riad to keep the text around for a couple of releases.

[mcsf]

I think aligning here is good, but I'll just note that on the block.json side things can also get complicated, as we have both type string and rich-text. These are the current existing pairings of type and source in the core block library:

// {"type":"array","source":"query"}
// {"type":"boolean","source":"attribute"}

   {"type":"rich-text","source":"rich-text"}

   {"type":"string","source":"attribute"}
   {"type":"string","source":"html"}
   {"type":"string","source":"raw"}

`jq` query

jq -rc '.attributes.[]? | select(.source) | {type, source}' packages/block-library/src/*/block.json | sort -u

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

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: oandregal <oandregal@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@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.

[oandregal]

@youknowriad @ntsekouras every breaking change we've introduced would qualify as something we could maintain a few releases. This change is no different from others we've done (groupByField to groupBy.field, no longer providing an empty value for the select control, remove boolean form control, etc.). I worry that if we start doing it for every breaking change, it'll impact our velocity and ability to perform changes. All consumers we have so far are npm packages that can decide when to update, so we're covered.

[oandregal]

@mcsf Thanks for the nudge. Taking the following atts from the button block:

		"linkTarget": {
			"type": "string",
			"source": "attribute",
			"selector": "a",
			"attribute": "target",
			"role": "content"
		},
		"rel": {
			"type": "string",
			"source": "attribute",
			"selector": "a",
			"attribute": "rel",
			"role": "content"
		},
		"placeholder": {
			"type": "string"
		},
		"backgroundColor": {
			"type": "string"
		},
		"textColor": {
			"type": "string"
		},

These are the Field API types I'd assign to each:

• linkTarget: url
• rel: text
• placeholder: text
• backgroundColor: color
• textColor: color

It's not a 1:1 match from block attribute types to Field API types. We're going to need better heuristics to match an attribute to the proper Field API type (perhaps format and others as discussed there?), and there will be a mapping of some kind. Whether the Field API type is called text or string won't make a big difference. That mapping will still be necessary. If anything, it can be argued that using string in the Field API can create confusion.

I scaffolded this PR a few months ago in a conversation with Riad/Héctor. I didn't give it much thought back in the day, to be honest. In updating it to today's code, I already removed some parts that were suggested back in the day (elements to enum) because it was confusing. Now that you nudged me to think more about this, I cannot help but think that this is also unnecessary.

I don't feel strongly either way, but given the cost/benefit, I lean towards maintaining the status quo. I'm going to let this PR sit here for a few days in case the conversation evolves.

[youknowriad]

before WordPress 5.0 we had a policy in Gutenberg where we'd introduce a breaking change, if it's easy to shim we shim it for 2 releases and remove the shim in the third release. Maybe something like this could work here.