Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Overview
This module currently implements #3440578: [PP-2] JSON-based data storage proposal for component-based page building as proposed by @effulgentsia. This is achieved using:
src/PropExpressions, to consistently refer to SDC component props and Drupal field types' propssrc/PropSource, to consistently describe how an SDC component prop source should be populated (and hence it usessrc/PropExpressions), and allows evaluating those sources to retrieve the actual values to be passed as SDC component propssrc/Plugin/DataType/ComponentPropsValuesstoressrc/PropSourcessrc/Plugin/FieldType/ComponentTreeItem, which is "the XB field type", and it usessrc/Plugin/DataType/{ComponentPropsValues,ComponentTreeStructure,ComponentTreeHydrated}
A diagram describing this was added in #3454677: Diagram tying the product requirements + decisions together and can be viewed at https://git.drupalcode.org/project/experience_builder/-/blob/0.x/docs/di...
Out of scope for this: src/SdcPropJsonSchemaType and src/SdcPropToFieldTypePropMatcher — up to #3450496: Clarify the "shape matching" bits: namespaces, `CODEOWNERS` and as issue queue component to first bring more clarity there, and ideally also document it as part of that issue.
Proposed resolution
- ✅ Describe the current data model in some detail, in a new
docs/*.mdfile, with each of the above concepts explained: their purpose, the rationale behind them, and at a high level what parts of their intended scope already exist today vs still need to be created. - ✅ Capture the current data model as an ADR (see #3454669: Record Architecture Decisions — to scale to many people + many timezones), knowing full well that it could still change based on what we learn while working on this, as well as the ongoing discussion over at #3440578: [PP-2] JSON-based data storage proposal for component-based page building. The ADR should be able to refer back to the docs written in the first step.
… because until those two documents exist, it's going to remain very difficult for people to join building Experience Builder, as well as for people to provide constructive criticism.
User interface changes
None.
Issue fork experience_builder-3461490
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
wim leersNow that #3461499: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings is in, doing this is even more important.
And now that #3460856: Create validation constraint for ComponentTreeStructure is in, I can do this with more detail, and with more confidence.
Comment #4
wim leersADR draft is ready.
Docs next.
I'm assuming this data model will remain largely unchanged between today and DrupalCon Barcelona (in ~1.5 month). For Barcelona, we'll tag
0.1.0, per #3454094: Milestone 0.1.0: Experience Builder Demo.Comment #5
wim leersDidn't push this forward today, but #3450308: Create an Open API spec for the current mock HTTP responses instead. Which also is documentation-related 👍
Comment #6
siramsay commentedI just added the comment above, unsure why my GitLab profile doesn't match up with this one.Saving this comment fixed that.Anyhow, I read/reviewed it and I understand it clearly. A few capitalizations missing at the beginning of list items, but unsure how strict you are on that.
Comment #7
wim leersRelated: #3450308: Create an Open API spec for the current mock HTTP responses landed. That helps with understanding the big picture, but then the client-server communication part. This issue is solely concerned with server aspects.
@siramsay Thanks for the review! 😄
Comment #8
wim leersRedy for review!
Comment #10
wim leersAddressed all of @longwave's feedback.
Would like to get @effulgentsia and @f.mazeikis to sign off on this too. It's the EOD for @f.mazeikis. So assigning to @effulgentsia. @effulgentsia, please assign to @f.mazeikis after you've reviewed it 😊
Comment #11
effulgentsia commentedI think this all looks great at capturing the current state of things. There's a few unresolved threads from @longwave, but I think those are proposing changes that can be discussed/explored in separate issues and I don't think should hold up merging these docs in.
Passing the review baton to @f.mazeikis :)
Comment #12
wim leers@effulgentsia Thanks! :)
Created 2 follow-up issues based on @longwave's comments in https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...
Comment #13
wim leers#11: huh, I did respond to everything an hour after he posted that, but GitLab didn't show those to me! 🤪 Addressed all things I missed last night 😊👍
Off to @f.mazeikis now!
P.S.: it'd be great to get @tedbow to chime in too, but he's out the rest of the week. I think it'd be better to land this sooner rather than later. I'll be out in a few hours too. Please land this even in my absence. We'll keep evolving the
docs/data-model.mddoc (for example when #3468269: `ComponentTreeStructure` data type: simplify the stored structure lands), but having this first ADR captures our intent for everyone to find in a compact representation.Comment #14
f.mazeikis commentedReviewed, re-read and approved. Nice amount of details in there, the Terminology section alone is worth it's weight in gold. I see @wim-leers is already responding to @longwave threads, so we just need @tedbow to have a look.
Comment #16
tedbowThis looks good. I accepted my own suggestion in the MR
Comment #17
wim leersWith:
I've already opened several follow-ups based on @longwave's feedback (#3468269 + #3468272), and I'm sure that when he gets more involved over time, that he'll make implementation changes which we'll then update these docs for 😊
Comment #19
wim leers