Require component instances to use the field type + storage + instance settings dictated by the `Component` version (#3560005) · Issues · project / canvas

Require component instances to use the field type + storage + instance settings dictated by the `Component` version

>>> [!note] Migrated issue   Reported by: [wim leers](https://www.drupal.org/user/99777) Related to !358 >>> <h3 id="overview">Overview</h3> @jessebaker on <a href="https://git.drupalcode.org/project/canvas/-/work_items/3558719" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3558719</a>'s MR: <blockquote> > I do wonder if the API should be relying on what data the client is sending to this PATCH endpoint. Does the server know the component that is being patched and can it therefore access the correct/original 'sourceTypeSettings' rather than having to rely on them being sent in the request. </blockquote> <h4>Background: intentionally stateless</h4> The <code>/canvas/api/v0/form/component-instance/{entity_type}/{entity}</code> internal HTTP API (so the <code>\Drupal\canvas\Form\ComponentInstanceForm</code> controller) was designed to do be stateless: it generates a form for a component instance, and is given all the necessary information. IOW: it's intentionally stateless (other than Drupal AJAX form state); the server is told: <ul> <li>which <code>Component</code> the component instance is of</li> <li>the inputs for that component instance</li> <li>the UUID of the component instance</li> </ul> However… That architecture dates back all the way to early XB/Canvas days. It was introduced in July 2024: <a href="https://www.drupal.org/project/experience_builder/issues/3461422" title="Status: Closed (fixed)">#3461422: Evolve component instance edit form to become simpler: generate a Field Widget directly</a>. Since then, we gained versions within <code>Component</code> config entities (<a href="https://www.drupal.org/project/experience_builder/issues/3523841" title="Status: Closed (fixed)">#3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row</a>), which also made sure that the client model's "component" identifier gained a version: <code>componentID@componentVersion</code>. And within each version, we store exactly the kind of information you're referring to! So, in principle, it _is_ now possible to do what you say. The only caveat is that in principle, we allow each component instance to deviate from what the associated <code>Component</code> version dictates. For example, version <code>1sdfsdf</code> might have picked the <code>url</code> field type for some prop, but version <code>2badb</code> might have picked the <code>link</code> field type. Now, for the tricky bit: it's not required for a component instance to comply with this — all Canvas cares about is storing a prop source that is able to populate the SDC or code component prop without causing validation errors. In the early days that seemed wise: it allowed for rapid iteration, freedom for component trees to do what they want, and so on. It also predates <code>Component</code> versions by over a year! Today though, that seems like an unnecessary and even brittle ability. If we'd remove that ability to deviate from what the <code>Component</code> version specifies should be the field type (and storage + instance settings), we'd make update paths simpler. It'd also enable the (un)collapsing of stored data (introduced by @larowlan and I in <a href="https://www.drupal.org/project/experience_builder/issues/3523841" title="Status: Closed (fixed)">#3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row</a>) to be guaranteed rather than a "only if there was no deviation". Deviations were specifically allowed in <a href="https://www.drupal.org/project/experience_builder/issues/3538487" title="Status: Closed (fixed)">#3538487: Don't allow passing uncollapsed inputs if using default expression</a>. This is about disallowing that. 👉 That would make <a href="https://git.drupalcode.org/project/canvas/-/work_items/3463996" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3463996</a> far easier to achieve, because all instances of a <code>Component</code> version would be guaranteed to be using the field type + storage settings + instance settings defined in the <code>Component</code> version! <h3 id="proposed-resolution">Proposed resolution</h3> Quoting <code>\Drupal\canvas\Plugin\Canvas\ComponentSource\GeneratedFieldExplicitInputUxComponentSourceBase::collapse()</code>: <pre>  /**    * Collapse prop source for storage whenever possible.    *    * StaticPropSources are dangling field item lists, which require a lot of    * metadata to be known: field type, storage settings, instance settings and    * expression.    * When a StaticPropSource is being stored (to populate some component prop),    * check if it matches that metadata in the `prop_field_definitions` for this    * component instance's referenced version of the Component config entity. If    * it does match, all metadata can be omitted, which significantly reduces the    * amount of data stored.    *    * @param \Drupal\canvas\PropSource\PropSourceBase $source    *    * @return OptimizedExplicitInput|PropSourceArray    *   Either:    *   - the collapsed prop source storage representation, which means either a    *     scalar or an array without a `sourceType` key    *   - the uncollapsed prop source storage representation, which means this    *     will be an array with a `sourceType` key.    *    * @see ::uncollapse()    */   private function collapse(PropSourceBase $source, string $prop_name): mixed {</pre><ol> <li>Remove ability for new Component instances to deviate, i.e. change the above to become a requirement rather than an option. </li><li>… but to ease the transition, consider allowing a component instance to deviate if it had already previously been </li><li>TBD </li></ol> <h3 id="ui-changes">User interface changes</h3> > Related issue: [Issue #3461422](https://www.drupal.org/node/3461422) > Related issue: [Issue #3523841](https://www.drupal.org/node/3523841) > Related issue: [Issue #3538487](https://www.drupal.org/node/3538487) > Related issue: [Issue #3463996](https://www.drupal.org/node/3463996) > Related issue: [Issue #3520449](https://www.drupal.org/node/3520449)

issue