Contrib.social

Consider renaming ComponentSource plugins to ComponentType

Open on Drupal.org →
Created on 22 May 2025, 11 days ago

Overview

When I started onboarding with Experience Builder, I found the terminology of "component source" quite confusing. I asked the rest of the XB team if they had ever considered "component type" as the term of choice for this concept.

As it happens, they very much had. The discussion happened in 📌 Add support for Blocks as Components Active and #3454519-10: [META] Support component types other than SDC, block, and code components → , where @larowlan came up with the name of "component source" (even earlier discussion in 🌱 [META] Support component types other than SDC Needs work leaned towards "component type"). But coming to it fresh, these folks said (in Slack) that they don't feel strongly about "component source" vs. "component type".

To be clear, this isn't critical; I don't feel strongly enough about it either to push too hard on this. But ComponentSource calls MediaSource to mind, which is a dramatically different concept (in my mind, media comes from somewhere...components are just there but have different abilities and powers). XB chose the term "source" because of the idea that, to XB, all components are treated basically the same way; the only thing that differs is what happens to power them in the backend. That does make sense.

And yet, ComponentSource plugins don't just provide components for XB to play with (although they do do that). They are also heavily referred to in the backend so that XB knows how to validate and interact with these components, and what their capabilities are. That feels more like a "type" -- i.e., what can this component do?

Opinions seem somewhat varied. @effulgentsia summed it up nicely:

My summary of the perspective difference between the words:

Source = how does the component come to exist within the site?

  • Block = provided by module via a PHP class with a Block PHP attribute
  • SDC = provided my module or theme via a YAML file
  • JS component = config entity

Type = what can the component do?

  • Block = run PHP code
  • SDC = not much (but that's not necessarily a bad thing for pure presentation components)
  • JS = leverage JS ecosystem (Tailwind, Radix, etc.)

Proposed resolution

Decide on whether we want to stick with "component source" to describe this concept, or change to "component type".

User interface changes

None either way. This would be strictly an API change, if it happens.

📌 Task
Status

Active

Version

0.0

Component

Code

Created by

🇺🇸United States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @phenaproxima
  • Comment 11 days ago →
    🇺🇸United States phenaproxima Massachusetts
  • Comment 11 days ago →
    🇺🇸United States phenaproxima Massachusetts

    I would like to mention one thing about ComponentSource sounding roughly analogous to MediaSource -- the reason MediaType plugins are not a thing is because MediaType is a bundle config entity -- same idea as NodeType. I think that, if the media system didn't have bundle entities, MediaSource plugins would be named MediaType plugins.

    XB, however, has nothing analogous to MediaType entities. So it should not necessarily be echoing Media's naming decisions here.

  • Comment 11 days ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • Comment 11 days ago →
    🇳🇿New Zealand danielveza Brisbane, AU

    I don't feel strongly about this one. I'm a soft +1 for ComponentType. In a ComponentSource (using it's current name), nothing is actually being sourced from anywhere. At this point it's handling the render and data transformation layers for use inside XB. This makes it feel more like a type to me, and I think @effulgentsia points at the bottom of the IS outline this in a really clean way that makes sense to me.

    At the moment we decocate cores plugin providers (BlockManager & ComponentPluginManager) to create/update XB component entities from existing plugins. We don't currently use any particular term or interface for these, but to me this is what should be considered a Component Source. Components are being sourced from another system like block or SDC currently, and LB and paragraphs in the future.

    Naming is hard!

  • Comment 11 days ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Yep, Daniel hits the nail on the head: the sourcing does happen, and that’s why the name conceptually makes sense, but it happens outside the source plugin itself, which makes the name a bit off.

    The thing is though, that depending on where the components are being sourced from (currently: 2 different plugin types, 1 config entity type, and later: anything), different implementations are needed. So truly having everything self-contained in the source plugin is AFAICT impossible.

    But perhaps one of you has a genius insight for how to change that? 🤓

  • Comment 10 days ago →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    Taking my last comment further: what if a component source plugin could declare the (forgive me) type of source discovery?

    Similar to how an entity type plugin declares its access

    And that that would then result in either

    discovery = FromPluginManager::class,

    Or from

    discovery = FromConfigEntityStorage::class,

    That’d help tie things together?

  • Comment 10 days ago →
    🇮🇳India mohit_aghera Rajkot

    I don't have strong opinion on `ComponentType` vs `ComponentSource`.
    However as non-native english speaker, I felt `ComponentSource` more convenient to realise that there are so x number of source plugin that allows XB component config entities to be created.

    Regarding declaring source discovery:
    Strong +1 from me.
    I faced the issue while working on Pinto integration.
    Since pinto object are standalone object, there was no easy way to identify and create Component config entities.
    I'm relying on hook_cache_flush to refresh the list and generate new `Component` config entities.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024