Allow mapping "List (integer)" field type to `type: integer` and "List (float)" to `type: float`
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3548686. -->
Reported by: [wim leers](https://www.drupal.org/user/99777)
Related to !137
>>>
<h3 id="overview">Overview</h3>
<p><em>Surfaced by @hoorooomoo at <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/canvas/-/work_items/3548298" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3548298</a></span>.</em></p>
<p><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3512854" title="Status: Closed (fixed)">#3512854: Determine core bug(s) and missing metadata that explain unmatched field type properties; make the reported % reflect reality</a></span> added code to stop trying to match the 3 "list" field types (integer/float/string), with the following commentary:</p>
<pre> // The `list` field types allows each field instance to define its own set<br> // of possible values. The probability of this exactly matching the explicit<br> // inputs for a component is astronomical.<br> // If we ever decide to allow this, then the `Choice` constraint must be<br> // correctly specified on it. Otherwise, `::toDataTypeShapeRequirement()`<br> // does not find any constraints and matches every such field instance<br> // against every integer/float.<br> 'list_float' => ListFloatItem::class,<br> 'list_integer' => ListIntegerItem::class,<br> 'list_string' => ListStringItem::class,</pre><p>That missed one key point though: mapping a predefined set of integers/floats (in such a field instance) to a <code>type: integer</code>/<code>type: float</code> prop works totally fine, with zero negative consequences.</p>
<p>(<del>No such luck for "List (string)", because typically the values stored in there are "machine names", things such as "be_nl", "be_fr", "be_de" … — or "light", "dark" — or "red", "blue", "green". As such, they are clearly <code>StringSemanticsConstraint::STRUCTURED</code>. Which doesn't make sense to map to <code>type: string</code>, which are for <code>StringSemanticsConstraint::PROSE</code>. See commit <code>01088091</code> that introduced this — it predates the use of the d.o issue queue!</del> → while accurate concerns, @lauriii proposed a way around them: <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/canvas/issues/3548749" title="Status: Closed (fixed)">#3548749: Allow mapping "List (string)" field type to `type: string`, with a twist: don't map the stored value, but its key/name/label</a></span>.)</p>
<h3 id="proposed-resolution">Proposed resolution</h3>
<p>Allow matching <code>list_float</code> and <code>list_integer</code> to <code>type: number</code> and <code>type: integer</code>, respectively.</p>
<h3 id="ui-changes">User interface changes</h3>
<dl>
<dt>Before</dt>
<dd>Such fields are not offered to link when creating a content template.</dd>
<dt>After</dt>
<dd>They now are:
<ol>
<li>Link: <img src="https://www.drupal.org/files/issues/2025-09-25/Screenshot%202025-09-25%20at%204.24.26%20PM.png">
</li><li>Result in rendered component instance: <img src="https://www.drupal.org/files/issues/2025-09-25/Screenshot%202025-09-25%20at%204.35.23%20PM.png">
</li></ol>
</dd>
</dl>
issue