Allow component source plugins that don't have a plugin_id setting

niharika.s → made their first commit to this issue’s fork.

@niharika.s: wow, so nice to see this almost done! 🤩

@larowlan:

I was expecting each plugin to be able to define it's own settings and hence SDC and block components could retain plugin_id, whilst JS components could use something else.

The problem with that is that that won't work with:

    id:
      # This ID intentionally does not use `type: machine_name`, because it is a composite ID that is better validated
      # using the `StringParts` constraint than the `RegEx` constraint.
      type: string
      label: 'Component'
      constraints:
        StringParts:
          separator: .
          reservedCharacters:
            - ':'
          reservedCharactersSubstitute: .
          parts:
            - '%parent.source'
            - '%parent.settings.plugin_id'

This guarantees consistent, meaningful Component config entity IDs.

See that last line there: that's immutable. There's no other way I know of in config schema to achieve this.

I think

  label: 'Block component settings'
  mapping:
    local_source_id:
      label: 'Block plugin ID'
      constraints:
        PluginExists:
          manager: plugin.manager.block
          interface: Drupal\Core\Block\BlockPluginInterface

is plenty clear: for every Block-sourced Component config entity, the local_source_id must be a block plugin ID. The validation constraint makes this firm.

And the equivalent for a component source using config entitities:

  label: 'Code component settings'
  mapping:
    local_source_id:
      label: 'JS Component ID'
      constraints:
        ConfigExists:
          prefix: experience_builder.js_component.

Thanks for taking this on, @thoward216!