Active
Project:
Drupal Canvas
Version:
1.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
22 May 2025 at 12:48 UTC
Updated:
4 Dec 2025 at 14:25 UTC
Jump to comment: Most recent
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 #3475584: Add support for Blocks as Components 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 #3454519: [META] Support component types other than SDC, block, and code components 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".
- Consider all aspects that such a plugin is responsible for, and including them in the plugin API. For example, currently they do not include discovery, and they likely should (see #7, +1'd in #8, and came up again in #3547579-27: Introduce a new cache tags aware prop shape repository, so changes affecting prop shape calculation can force the re-invoke of hook_canvas_storable_shape_prop_alter).
User interface changes
None either way. This would be strictly an API change, if it happens.
Comments
Comment #2
phenaproximaComment #3
phenaproximaI would like to mention one thing about ComponentSource sounding roughly like MediaSource: the reason MediaType plugins aren't 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 #4
wim leersComment #5
danielvezaI 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 #6
wim leersYep, 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 #7
wim leersTaking 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
accessAnd that that would then result in either
Or from
That’d help tie things together?
Comment #8
mohit_aghera commentedI 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.
So, having a separate class for discovery makes things easier for creating new ComponentSource plugins.
Comment #9
wim leersComment #10
lauriiiComment #11
wim leersNote that stabilizing
ComponentSourceplugins as a public PHP API has been decided to be out of scope for 1.0, which is why #10 makes sense 👍Comment #13
wim leersComment #14
wim leersComment #15
wim leers@mohit_aghera: that now has a near-RTBC MR: #3556327: Don't save `Component` config entities unnecessarily.
Comment #16
wim leers#3556327: Don't save `Component` config entities unnecessarily is in! That is a big step in the right direction. But much remains to be done.