Clarify "components" vs "elements" vs "patterns"

I've always viewed elements as a type of component. The reason they must be separate from components is because most of the time, you'd want your content creators using components instead of elements. When that's the case, it needs to be possible to disable elements from the page builder.

I created a Figma design to show case the different concepts and their relationship:

these are “opted in” from the list of installed SDCs using a config entity

Especially for elements, it seems that this is something you'd probably control in code instead of UI. It doesn't seem necessary to be able to control the available elements on a site level. It could be that elements is just one category.

THIS is where “locking” starts to become relevant, not in “elements”

I'm not sure what are you referring to by locking in this context? The internals of the component should not be editable when the component is being used. When the component is being used, it's only possible to modify props of the component, and insert components to the slots of the component. There could be a way to set up a component with a slot that has a default value, which allows editing the contents of the slot.

these MUST have a default value for each prop to ensure they always have a visual representation

This is the current hypothesis for ideal UX. This is something we need to work to confirm with UX.

1 pattern = 1 or more elements, similar to 1 component, but then in the Page Builder territory, and each time a pattern is used, it’s “copy by value” instead of “copy by reference” — meaning changing the pattern won’t update it everywhere.

This is somewhat correct. They are indeed “copy by value” instead of “copy by reference” . However, patterns would be created using the same building blocks that are available for the content creator. This means that if elements are not available for content creator, then patterns that may only use components too. These are usually created to define pre-configured configurations of the components that look good. For example, you could have a pattern that adds 3 card components side by side, because having one card component on its own doesn't look great.

I actually cannot find anything in the Requirents spreadsheet nor past discussions about “component variants”

I'll craft a user story to the requirements spreadsheet. I could also file an issue with some more information.

In our past discussions, we said that field formatters must be available early. If so, we must be able to express them. If so, exposing them as field blocks probably makes sense? It’d make the upgrade path easy too. OTOH, doesn’t that inherit all scalability problems? We could also make field formatters a distinct “component type” or “renderable”

The discussion so far has been that we'd expose fields through a single field block. This avoids the problem of creating a ton of derivatives. It's probably possible to convert the existing uses to something like that without too much disruption. I did a PoC on that last fall: #3365551-18: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points.

Can you confirm the misnaming of the already-committed config entity?

To me, it still seems like we shouldn't have a config entity per component. I personally think that the ideal DX would allow exposing components directly from code, without requiring a step in the UI. There was some concerns around components automatically appearing in the UI and becoming available for content creators. I'm wondering if we should approach that with tagging or categories? This way builder could select either specific components, tags or categories that they want to expose for the content creators. This way you could get rid of the additional step without having arbitrary SDC appearing in the UI.

What if there's a prop that you don't want content creators to be able to modify?

I would imagine in that scenario you would wrap the component with another component which sets a static value for the prop, and exposes rest of the props for the content creators. Then they would choose to only expose the wrapper component for the content creators.

If this config entity is something you disagree with, we urgently need more clarity on the product requirements, because I currently don't see any other way to meet the requirements — it seems that there's a conflict then.

Should we move the discussion to #3444424: [META] Configuration management: define needed config entity types or maybe even open a dedicated issue for this? I'd be happy to open that if you think it's a good idea.

In our past discussions, we said that field formatters must be available early. If so, we must be able to express them. If so, exposing them as field blocks probably makes sense? It’d make the upgrade path easy too. OTOH, doesn’t that inherit all scalability problems? We could also make field formatters a distinct “component type” or “renderable” (name TBD), which seems to make things simpler?

I'd be interested to understand more about the motivation here. Field formatters as we know them in Drupal(ones that output html) go against the concept of components only being passed structured values that they then place in their html.

What if there's a prop that you don't want content creators to be able to modify?

The internals of the component should not be editable when the component is being used. When the component is being used, it's only possible to modify props of the component, and insert components to the slots of the component.

This warrants more discussion. IMO components composed of other components should definitely be able to compose their forms by passing thru props and customizing what props are available on the authoring form otherwise we end up in the same situation various Drupal approaches and Acquia Site Studio have where every usage of a component in another component requires redefining fields on the parent form so they can be mapped from the parent to the child.

Back to the main question for this issue component vs element vs pattern. +1 to @laurii's take that elements are just a type of simple component. Expanding on the similar but different concepts touched on in the issue description for how components will be created/placed on a page. I've seen 3 main types of components that authors want to place:

• Standalone components: These are the components that will most commonly be placed in XB by authors, you place them on a given page and that's the only place they'll ever need to be rendered.
• Reusable components: These are components that are globally available, managed by site builders or by privileged authors they exist so that the same content can be placed on many different pages and when the content changes all the pages using the component show the newest content. This concept is implemented in core by blocks where reusable blocks can be placed in layout builder and in paragraphs through the paragraphs_library submodule.
• Blueprint components: These are what are being called patterns in this issue(not a huge fan of the patterns name btw). This is a set of components that have been authored either on an XB page or a separate pattern creation page and saved by a site builder or author to either the site or author's personal library of "patterns". These saved patterns are then available for the author to place when creating a page with XB but unlike reusable components that is a self contained reference to a component pattern components end up on the page as a preconfigured set of standalone components that have no concept of what their parent pattern is. Tossing out alternative names to pattern these could also be called stencils, templates, or blueprints. This is implemented for layout builder by https://www.drupal.org/project/section_library and not sure if paragraphs has an equivalent.

I'd be interested to understand more about the motivation here. Field formatters as we know them in Drupal(ones that output html) go against the concept of components only being passed structured values that they then place in their html.

I'm on the same page with you – conceptually they don't make a lot of sense in a component based system. The reason we'd be bringing in the field blocks is because it helps us avoid having to move all existing formatters to components. This is critical especially for sites using LB currently.

This warrants more discussion. IMO components composed of other components should definitely be able to compose their forms by passing thru props and customizing what props are available on the authoring form otherwise we end up in the same situation various Drupal approaches and Acquia Site Studio have where every usage of a component in another component requires redefining fields on the parent form so they can be mapped from the parent to the child.

I was referring to something else in my comment. I was mainly trying to explain the key characteristic of a component which is that you can only interact with it through props and slots, unlike with patterns where you can actually start changing the internals of the pattern once you've placed it. I agree we should try to design the system so that we can avoid this problem.

I've seen 3 main types of components that authors want to place

I agree with the 3 main types of components you listed here. I'm referring to the reusable components as "Global blocks" in this content type breakdown. It's definitely not the best term. 😅

not a huge fan of the patterns name btw

Me neither! I think our design team is calling them just "sections" right now since that seems to be a term that is used broadly within the industry. That's a little unfortunate given that Layout Builder is using that term for something slightly different.

Here's the currently proposed IA which may help get a sense of what the difference is: https://www.figma.com/board/odeJtdvynsTvUIUUpIqO8n/Proposed-component-IA.... How that connects to here is that:

1. Patterns are called "Sections". They are pre-defined compositions of components coming from other groups (elements, components, dynamic components, community components)
2. Blocks are called dynamic components because as @Wim Leers points out in #10, they are "renderable units powered by logic".

Based on that, we can answer that "sections" are essentially the same as what we are calling "patterns" here.

It is not conceptually that different from Layout Builder; sections are parts of a page. However, what's different from Layout Builder is how users create sections. In Experience Builder, sections can be created out of components, or they can be created using section templates. Section templates are just pre-configured components that constitute a section on a page.

FWIW, the current terminology is our hypothesis on what we believe makes sense based on competitive analysis. Acquia UX is in progress of researching if the proposed terminology and categorization makes sense for our target user: #3459088: Every XB `Component` config entity should have a `category` property.

@laurii Is this a part of the work that I am focused on?