- Issue created by @larowlan
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
This should also allow refactoring π Create validation constraint for ComponentTreeStructure Needs work to make it simpler π
- Assigned to larowlan
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Brought in the value objects and a normalizer. Will continue tomorrow
- Issue was unassigned.
- Status changed to Needs review
6 months ago 9:24pm 1 August 2024 - Merge request !137Draft: #3462235 - Value Objects for component tree π² β (Open) created by larowlan
- Assigned to wim leers
- Assigned to larowlan
- π¦πΊAustralia kim.pepper πββοΈπ¦πΊSydney, Australia
Wim Leers β credited kim.pepper β .
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Reviewed! (Review delayed due to π Introduce an example set of representative SDC components; transition from "component list" to "component tree" Fixed , I explained this in my review on the MR.)
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Thanks Wim, I'll pick this up again after vacation
- Status changed to Needs work
5 months ago 1:45pm 9 August 2024 - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Having introduced the very barebones
ClientSideRepresentation
object last night in π Improve or remove ComponentSourceInterface::getClientSideInfo() Active , and seeing the existence of both:-
π
ServerClientConversionTrait
Active
β to complement
ClientServerConversionTrait
that was introduced in ~2 months ago at [#347856] - π Add a param converter and DTO for XB data model Active
β¦ makes me realize that you probably just were able to see months into the future with this proposal π π€©
I definitely could not. Not until π Not all components have UUIDs, so rename to ID Active and π Add support for global regions Active had landed, both of which clarified the client-side data model, and it:
- has its rationale documented at
docs/adr/0005-Keep-the-front-end-simple.md
- has its structure documented at
docs/data-model.md
, section
Now that all that is in place (i.e. we know the client-side data model), I can totally see the value of what this MR originally envisioned: the ability to "upcast" any data source into the data model expected by the client, which will allow loading it into the client and then saving it into an XB field.
That means I'm now somewhat disagreeing with point 1 of my August 8 comment at https://git.drupalcode.org/project/experience_builder/-/merge_requests/1.... Although I do still think it'd probably be more powerful/interesting to be able to convert to the server-side data model directly, I'm not sure that that is required or even sensible β because I suspect that we'd never auto-convert "Layout Builder data" to "Experience Builder data", but instead make the transition trivial, while still requiring a human to do so.
Conclusion: I think that what I wrote in August might be the ideal scenario from a migration path POV, but I doubt it's realistic to achieve perfection. To overcome that imperfection, we could require human intervention, which is exactly what your proposal achieves. Thoughts?
-
π
ServerClientConversionTrait
Active
β to complement
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
The other thing this enables is the BC layer for Paragraphs and Layout builder for π Decouple tree storage, introduce tree storage plugins Active
Because we will need a contract for 'here is an entity, load me a tree for it' and the value object is 'the tree' in that contract.
This will allow us to load legacy layout builder layouts (a subset of what XB supports) and edit them in XB, saving them as XB data - allowing sites to progressively update (one edit at a time).