>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3503272. --> Reported by: [wim leers](https://www.drupal.org/user/99777) >>> <h3 id="overview">Overview</h3> <p>During the implementation of <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3499931" title="Status: Closed (fixed)">#3499931: HTTP API for code component config entities</a></span>, something tangentially related was discussed between @balintbrews, @effulgentsia and @larowlan. That led to this comment by B&aacute;lint:</p> <blockquote><p> I would like to propose that we don't use the <code>machineName</code> property as the <code>id</code> entity key in the <code>JavaScriptComponent</code> entity. We would like to allow users to update the machine name of a code component, which is not possible if that property is the <code>id</code>.</p> <p>We could use the UUID as the <code>id</code> instead, which would be ideal for the HTTP API.</p> <p>I already had a conversation about this with @larowlan and @effulgentsia, and got &#128077;&#128077;. If this significantly delays landing this issue, a follow-up is fine, I already have the code written in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3499947" title="Status: Closed (fixed)">#3499947: Managing code components in library</a></span> with <code>machineName</code> as the <code>id</code>. </p></blockquote> <p>&mdash; B&aacute;lint at <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3499931" title="Status: Closed (fixed)">#3499931: HTTP API for code component config entities</a></span>.</p> <p>However, this caused some additional consequences, in particular wrt XB product requirement <code>14. Configuration management</code>. @wimleers surfaced concerns about that in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3499931" title="Status: Closed (fixed)">#3499931: HTTP API for code component config entities</a></span>. In <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3499931" title="Status: Closed (fixed)">#3499931: HTTP API for code component config entities</a></span> @wimleers decided to defer it to this follow-up, with a concrete proposal:</p> <blockquote><p> So, not throwing away what @larowlan did, just extracting that into a follow-up MR. I think all of those changes <em>could</em> happen as planned, with a few changes: disallow changing the machine name once a corresponding <code>Component</code> exists (which requires modifying the new constraint @larowlan added), and continue to use the machine name to refer to it.</p> <p>I think we could even use the <code>\Drupal\Core\Entity\EntityTypeInterface::getKey()</code> infrastructure for this, and use a new <code>xb_component_local_source_id</code> to identify that actually the machine name should be used, not the <code>JavaScriptComponent</code> config entity ID &mdash; related: <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/experience_builder/issues/3502982" title="Status: Closed (fixed)">#3502982: Rename ComponentSource settings' `plugin_id` to `local_source_id` or similar to not bias towards source plugins that don't use plugins under the hood</a></span>. That would result in the stored component trees again having meaningful <em>names</em> for every component instance (much better for debuggability/DX!). The only place where you'd then continue to see UUIDs showing up instead of the machine name is in the <em>config dependencies</em>. That'd be more balanced IMHO.</p></blockquote> <p>Furthermore, @effulgentsia explained in <a href="https://www.drupal.org#comment-16037322">#12</a> why for the "code components importing other code components" use case, we <em>also</em> want mutable machine names, for refactoring/code clarity purposes.</p> <h3 id="proposed-resolution">Proposed resolution</h3> <ol> <li>Bring back what @larowlan did in <a href="https://git.drupalcode.org/project/experience_builder/-/merge_requests/586/diffs?commit_id=63c5b700d4ed4f54517433f8ca943d51816198b2">https://git.drupalcode.org/project/experience_builder/-/merge_requests/586/diffs?commit_id=63c5b700d4ed4f54517433f8ca943d51816198b2</a> through <a href="https://git.drupalcode.org/project/experience_builder/-/merge_requests/586/diffs?commit_id=aa7c1d02dc0ee0a75dc43dc4de9623afbc645c3d">https://git.drupalcode.org/project/experience_builder/-/merge_requests/586/diffs?commit_id=aa7c1d02dc0ee0a75dc43dc4de9623afbc645c3d</a>.</li> <li>disallow changing the machine name once a corresponding <code>Component</code> exists (which requires modifying the new constraint @larowlan added) </li><li>continue to use the machine name to refer to it, by using <code>\Drupal\Core\Entity\EntityTypeInterface::getKey()</code> infrastructure for this: use a new <code>xb_component_local_source_id</code> to identify that actually the machine name should be used, not the <code>JavaScriptComponent</code> config entity ID </li><li><del>but first discuss the consequences for config management that @wimleers surfaced</del> fine by @lauriii per <a href="https://www.drupal.org#comment-16032273">#8</a></li> <li>and first discuss the consequences for allowing "code component" machine names to be changed at any time</li> </ol> <h3 id="ui-changes">User interface changes</h3> <p>None.</p> > Related issue: [Issue #3499931](https://www.drupal.org/node/3499931) > Related issue: [Issue #3464042](https://www.drupal.org/node/3464042) > Related issue: [Issue #3310170](https://www.drupal.org/node/3310170) > Related issue: [Issue #3499919](https://www.drupal.org/node/3499919) > Related issue: [Issue #3509115](https://www.drupal.org/node/3509115) > Related issue: [Issue #3520449](https://www.drupal.org/node/3520449)