Skip to content

Draft: #3454519 Add notion of source and tree storage plugins and a component repository.

Lee Rowlands requested to merge issue/experience_builder-3454519:3454519-pluggable-storage-components into 0.x

What this unblocks

  • Adds support for blocks.
  • Decouples from SDC
  • Adds roadmap for theme builder support.
  • Adds roadmap for layout builder and paragraphs legacy support in place.

Details

Adds two new plugin types as follows:

  • Component Source plugin
  • Component Tree Storage plugin

Component source plugin

This decouples the component config entity and component tree from SDC components. There's a SingleDirectoryComponent implementation that all the existing logic moves to Adds two additional implementations as follows:

  • Blocks - this will support blocks (e.g. views, menus) as well as a bridge to layout builder
  • Layout (via submodule) - this will support layouts for a bridge to layout builder

Paves the way for:

  • Theme builder component - we can create a content-entity here (e.g with fields js, css, twig, props, slots) and build components from the DB based on that
  • Paragraphs support - could be in contrib or a sub-module

Component tree storage plugin

Decouples the component tree loading from the component tree field. There's an implementation for ComponentTreeFieldItem that holds the existing logic Starts to scaffold a layout builder version in a sub-module that in could possible be a BC layer for layout builder (I'll keep going on this). Adds value objects for component tree instead of array PIs Also opens door to:

  • storage of default values (e.g. equivalent to LB defaults).
  • additional view modes in separate fields (something LB can't do)
  • paragraphs support for legacy

Still to do

At present this branch assumes that a component is a config-entity ID for the component config entity. For something like the layout builder or paragraphs BC layer, that won't work - it would require having a component defined for each in use block/layout when you enable the module.

I will add the notion of a component respository. I will move the component interface class away from a 1:1 binding to the config entity and instead make it stand alone. The component repository will collected tags services that can provide component definitions. I will add one that wraps the config entity. I will add another in the LB sub-module that bridges legacy layouts/blocks in LB. We could add one for paragraph types too.

This should give us the flexibility we need. I will do that before I mark this as ready.

Also needs more tests, particularly of the AJAX interactions

  • Add component repository
  • Add a tagged service for loading components from config entities
  • Add a LB example in sub-module for loading layouts/blocks
  • More tests
  • Documentation/diagrams
  • Roadmap for follow-up tasks (paragraphs support, theme builder support)
Edited by Lee Rowlands

Merge request reports