🇧🇪Belgium @Wim Leers

Congrats!

Unpostponed ✨ [PP-1] Include component props form in undo Postponed and ✨ [PP-1] Update preview automatically when component props are updated Postponed .

Thanks for that epic screenshot 🤩

✨ Contextual form values need to be integrated with Redux Active is in! 🥳

✨ Contextual form values need to be integrated with Redux Active is in! 🥳

✨ Contextual form values need to be integrated with Redux Active is in! 🥳

Working to get this issue's status/relevance updated, but blocked on @lauriii's confirmation at #3463999-7: [PP-1] Auto-generate Component config entities for all discovered SDCs that meet XB's minimum criteria → .

Asked @lauriii to confirm he agrees with the proposed resolution, especially with an eye towards 📌 [PP-2] Add ComponentAuditabilityTest Active .

Follow-ups:

• #19.1: 📌 [later phase] [PP-1] When the field type for a PropShape changes, the Content Creator must be able to upgrade Postponed (and I realized it had a blocker itself: ✨ [later phase] PropShapes' JSON schema must match exactly with FieldType's storage format — what if you want to use another FieldType? Active ), and then the 3 at the bottom of #17:
• 📌 [PP-1] Auto-generate Component config entities for all discovered SDCs that meet XB's minimum criteria Active
• 📌 [PP-2] Remove Component config entity's add/edit form Postponed
• 📌 [PP-1] Introduce `FieldTypeStorageForJsonSchemaDefinition` plugin type Postponed

  Bonus follow-ups: 📌 Component config entity should validate that the SDC actually (still) exists Active + 📌 [PP-2] Add ComponentAuditabilityTest Active .

  I'll continue working on this MR on Monday. Now: time for blog posts :)

Wim Leers → created an issue.

Actually, the Component config entity already handles this, largely. So we don't need all that infrastructure.

But we're missing some validation here.

Wim Leers → created an issue.

Wim Leers → created an issue.

Wim Leers → created an issue.

This is less urgent than 📌 HTTP API: new /xb/api/meta-form route to load form for editing entity meta fields Active .

Wim Leers → created an issue.

Thoughts, @lauriii?

Just realized that this is actually far out because of ✨ [later phase] PropShapes' JSON schema must match exactly with FieldType's storage format — what if you want to use another FieldType? Active .

Wim Leers → created an issue.

Wim Leers → created an issue.

Wim Leers → created an issue.

Went for pragmatism and fixed the one remark I had. Even if @tedbow disagrees, then 99% of what he proposed is in, I only omitted 1%. Progress FTW. 🚢

#39: Yes, there are still plenty of unresolved questions. But given the early stages of this project, I think that's unavoidable. Especially because we're working based on 64 concise product requirements and @lauriii is working to get designs

Regarding smoke and mirrors: I think ✨ Contextual form values need to be integrated with Redux Active and its follow-ups ( ✨ [PP-1] Include component props form in undo Postponed , 📌 [PP-2] Redux sync on ALL prop types, not just ones with a single [value] property Postponed , more to come) are getting rid of the smoke (and hence revealing there are no mirrors, except maybe broken ones — sorry, the temptation was too great 🙈). Yes, it will all need to become clearer. But we're iterating towards more clarity, and to discover ASAP whether what each individual thinks (based on their expertise) should work, actually works.

Yes, there will be many more follow-ups. But no, they're not all created ahead of time. Yes, that makes it more difficult for others to see where this is going exactly. But we don't know where this is going exactly either!

It's obvious to everyone that XB is nowhere near production-ready (and nowhere near many other things), but we are developing this in the open from day 1.

🌱 UX design tracker Active is growing steadily, so it's gradually becoming easier for everyone, including us working on XB full time, what the exact intended end goal is.

I suspect/hope @lauriii has done some thinking around this already?

Wim Leers → created an issue.

Wim Leers → created an issue.

While Ted starts working on this, 📌 Refactor SdcController::preview() to use ComponentTreeHydrated Active can happen in parallel. Then this issue updating \Drupal\experience_builder\Plugin\DataType\ComponentTreeHydrated will automatically result in SdcController::preview() supporting actual component trees too 👍

Wim Leers → created an issue.

Are tests feasible for this? 🤔

FYI: this will also unblock ✨ [PP-1] Update preview automatically when component props are updated Postponed — but unlike 📌 [PP-2] Redux sync on ALL prop types, not just ones with a single [value] property Postponed , that has no additional blockers, so it will become immediately unblocked upon this landing.

Issue rescoped 👍

Crafted a fairly detailed proposed resolution.

This blocks 📌 [PP-1] HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context Postponed too.

See #3455975-5: [PP-1] HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context → .

All originally identified blockers are in. But 📌 Create new `PropShapeInput` config entity type Active changes things.

Issue summary fully updated 👍

@tedbow will be working on #20 once he finishes the issue blocking this one: 📌 Create validation constraint for ComponentTreeStructure Needs work . I just reviewed it, and it's close 👍

Actually, having seen ✨ Contextual form values need to be integrated with Redux Active in action, I think this is already implemented there? 😅

@lauriii, do you want to rescope this issue to handle #5 specifically? Because right now, the entire preview is updated — i.e. the entire component tree is re-rendered.

So I think rescoping this to would make sense.

(The even more efficient thing @catch is talking about in #7 requires the AST work in 🌱 [META] Real-time preview: supporting back-end infrastructure Needs work to be done, what I'm proposing here would be an easily achievable intermediary step.)

Clearly, @Utkarsh_33 has already started writing tests prior to 📌 DDEV support for Cypress tests Needs work being ready, so removing the prefix 🚀

@Utkarsh_33 FYI: see what @hooroomoo wrote in #21, which I explained in some more detail at https://git.drupalcode.org/project/experience_builder/-/merge_requests/9... 😊

Wim Leers → created an issue.

Merged in upstream, CI should be green again 👍

📌 Implement component states Fixed landed yesterday, so this is now unblocked 😊

Those screenshots look great, @Gauravvvv! 🤩

Keeping at , but IMHO this should be integrated with AppConfiguration (introduced by #3452582) — see MR review.

👏 — zero remarks, because this test improvement is exemplary: it makes the test not only more robust, but also an order of magnitude easier to understand 🤩

Wow, that looks much better! 👏

I'd even use the word impressive — it's nice to see that when we use Symfony's Validation component "as intended", that it is so much clearer than if there's Drupal's layer of abstraction (either config schema or Entity/Field/Typed Data) in between 🤯

It may be possible to do this within one MR, but if there are prop types that prove challenging I think it is reasonable to make those separate issues.

Indeed, let's find out :)

See my related comment at #3462441-15: Contextual form values need to be integrated with Redux: start with single-property field types → .

I think that for most field types, your remark will end up being true, but not for all. I think we might need some talking to the server for some props … but I will hopefully be wrong 😄

Still, for the ~90% case, I think what you wrote here will be feasible … and obviously would result in a much better UX (no network latency)!

It will be much easier to implement when […]

💯 — plus, then there should be a broader spectrum of "widget/form complexity" — because StringItem's widget is on one extreme, and ImageItem's is pretty much on the other extreme 😅

Thanks for creating 📌 [PP-2] Redux sync on ALL prop types, not just ones with a single [value] property Postponed , that helps clarify the intentionally-out-of-scope parts of this issue. I just updated the title to make it clear what the difference is between this issue and its follow-up 👍

That would of course need to happen, and I'll make it more explicit in the code.

👍

but if thats concerning it's NBD to do it all here and postpone this on #3463583

Hell no! 😄 We want to iterate in small pieces, and now that there is a follow-up and you'll make the code/docs more explicit, I have no hesitation to land this 😊 Especially because it will surely help discover additional next steps on the front end.

I'm not sure if the solution will be a more clever parsing of the Drupal selector or if we figure out server side and provide that info in an additional attribute.

Interesting! I think that could totally work for most field types. 👍

Given only docs (including a @todo <follow-up issue URL> comment) and a screenshot are missing, and some minor remarks on the MR, I pre-emptively approved the MR, so you can address those bits and merge this MR, to end your week on an epic note 😊

💯! 😄

Oh, and a screenshot of this in action, please 😄

Detailed review on the MR 🏓

I could see this being sufficient for now, to meet 🌱 Milestone 0.1.0: Experience Builder Demo Postponed: needs info goals.

But I don't see yet how this can fulfill all needs, so at minimum, this AFAICT needs follow-ups. How many follow-ups probably depends on what I missed aka what you can provide a solid answer to :)

Finally, some documentation, even if it's sparse, would help grok this and clarify next steps — InputBehaviors should explain what assumptions it makes WRT widgets' name attributes matching the Field Type property structure exactly, those values not needing transformations, how/if either of those could evolve, etc.

Just discussed #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings → with @laurii, he agrees that all defaults should be specified in the SDC, not in a Component. See #3461499-19: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings → and preceding comments.

That means this is obsolete.

Discussed #17 with @lauriii. His replies:

1. Yes, but needs follow-up to devise a UX to allow existing StaticPropSources using a previous field type+widget to update to the new one.
2. Yes
3. Yes

He agreed with the 3 follow-ups proposed at the bottom of #17.

We also discussed #18, and he prefers the "alternatively" — so repurposed that 👍

P.S.: Note that this also blocks 📌 Create a component for testing form backend + frontend integration Active .

Working on it, and as of commit e83470a84c89907bcdd73898485e5a78f03a383f, you should be unblocked here, @bnjmnm. For now, it'll require you to have 📌 Create new `PropShapeInput` config entity type Active applied.

But really, the point here is that such an "all possible shapes" component exists (which it already does) and has a working right sidebar (which will be the case after 📌 Create new `PropShapeInput` config entity type Active ).

So: there's nothing left to be done here for now, except wait until #3461499 is done, and then revisit.

#7 reproduced, and now with a failing test:

• commit: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...
• CI: https://git.drupalcode.org/project/experience_builder/-/pipelines/233901

I'll test this with 📌 Create new `PropShapeInput` config entity type Active — that issue should make this one much easier to push forward 🤞

📌 Load assets inside preview Active is in now, so now it's definitely actionable.

Also finally updating the issue title, per:

This component preview would simply be yet another <iframe>, with user-select: none; to disallow interaction, rather than an image? 🤔

oh d.o 🤪

@bnjmnm clarified: "non-components" is currently only root (the client equivalent of \Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure::ROOT_UUID on the server), but it may be non-SDC components once 🌱 [META] Support component types other than SDC Active lands. 👍

Discussed with @lauriii. Now that 📌 Create new `PropShapeInput` config entity type Active is virtually done, it makes sense to keep this blocked on 📌 Create new `PropShapeInput` config entity type Active .

But yeah once you have unlocked slots in more than one view mode there is a lot to deal with. One way to deal with it would just be to prevent it everywhere except full/default.

Interesting proposal! WDYT, @lauriii?

AFAICT no back-end work is necessary here. To clarify #2:

• Loading a preview without CSS/JS — has been possible for weeks now.
• Loading a preview with CSS/JS — will become possible once 📌 Load assets inside preview Active lands, and it's on the verge of landing!
• ⇒ generating a full preview of a single SDC is as simple as sending a subset of the client-side layout+model to \Drupal\experience_builder\Controller\SdcController::preview()

😄

Since only front-end work remains, making 🌱 [META] Early phase front-end work coordination Active the parent 🚀

Looks great, just one question about what these "non-components" are 😅

Also: END-TO-END CYPRESS TEST!!!!!!! 🥳

Oh, and once this lands, 📌 [PP-1] Media Library integration Postponed becomes trivially unblocked: it'll only require:

1. new configuration to allow declaring a preference for image vs media (which oddly would not be possible through a new experience_builder.settings.yml config, only through a new config entity, because simple config cannot have module nor config dependencies)
2. updating \Drupal\experience_builder\SdcPropJsonSchemaType::findFieldTypeStorage() to respect that configuration

Those 2 things would be in an MR for that issue which I could start and then the front-end team could continue.

Alternatively, I could repurpose ✨ Hardcode image props to use the media widget temporarily Active for that, so that #3454173 can stay focused on the bigger picture, of making that media library widget actually work (well).

This is not for 🌱 Milestone 0.1.0: Experience Builder Demo Postponed: needs info , so marking for a later phase.

More context: #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings → .

Per #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings → .

The \Drupal\experience_builder\Form\ComponentEditForm UX became simpler:

Discussion with @lauriii

Yesterday morning, prior to writing #15, @lauriii and I met and discussed this problem space in detail.

The key outcomes of that discussion:

1. XB will require that an SDC provides an example value for it to be surfaced in XB. IOW: the examples array must not be empty, and XB will use the first one. ⇒ Removes the need for 25% of what the Component config entity provides.
2. @lauriii was heavily leaning towards "no UI" and "logic with an alter hook".
3. Tricky: complex shapes, like json-schema-definitions://experience_builder.module/image — those would need a plugin system to provide the appropriate field type + field storage.

This issue: current MR state and current consequences

This issue proves it's possible to generate the default field_type, expression and field_widget value for each prop. ⇒ Removes the need for 75% of what the Component config entity provides.

This issue did implement it all as logic (i.e. with nothing stored as a config entity — see my comment #15 for why that turned out to be trickier than I thought when I created this issue), with a TODO for an alter hook.

As demonstrated in #16, this means the scope for 📌 [PP-1] Add support for matching SDC prop shape: {type: string, enum: …} Postponed changes to only having to worry about matching existing field instances that can be adapted to match the SDC prop's enum values.

Questions for @lauriii prior to landing this MR

1. Is it acceptable for the logic that determines which field type + widget to use to change and hence newly created instances of this component to potentially use a different field type than the pre-existing component instances?
2. SDC supports default *.component.yml-defined values. But that won't work for e.g. a default image. Is it okay for XB to layer on support for that by auto-discovering a propname.(gif|png|jpg|…) file in the SDC's directory? 🤔 (Will add this to 📌 [SPIKE] Comprehensive plan for integrating with SDC Needs work , to potentially add that to upstream SDC.)
3. Is it acceptable that the default value sourced from a component's examples cannot be overridden on a per-site basis?

I think the answer to the first question is "yes". (Note that every stored StaticPropSource is self-contained: the user will continue to be able to edit it, even if it's a completely different field type.)

If the answer to the second and third questions is "yes", then we can in principle remove the Component config entity. But that would introduce a huge risk: it'd make exporting/sharing configuration (in the future: 🌱 [later phase] [META] 7. Content type templates — aka "default layouts" — affects the tree+props data model Active , but now: config/optional/field.field.node.article.field_xb_demo.yml, which has config dependencies on the Component config entities it uses) brittle.

Therefore I think it'd be preferable to keep Component config entities under the hood — without showing any of that in the UI. I think that would also keep the door open for supporting per-site default values in the future, plus it will likely help with 🌱 [META] Support component types other than SDC Active .

If you agree, then I'll create three follow-up issues:

1. one that generates Component config entities for all discovered SDCs 1) upon installing XB, 2) upon installing a new module or theme
2. one to remove \Drupal\experience_builder\Form\ComponentEditForm after that auto-generation is happening
3. one for computing the appropriate field type + storage for $ref-defined prop shapes

So, can you please check if anything is missing from that all-props component? If you can't find anything missing, we can mark this issue as obsolete and unpostpone the issue it is blocking.

This component already exists, for the very reasons cited here: tests/modules/sdc_test_all_props/components/all-props/all-props.component.yml.

It's existed for \Drupal\Tests\experience_builder\Kernel\SdcPropToFieldTypePropTest, precisely for — but long prior to us having the ability to generate widgets, just finding viable storage candidates.

(It has even existed before the 0.x branch was created!)

And I'm literally on the path towards making exactly the intent of this issue feasible: #3461499-16: Introduce new `PropShapeInput` config entity type → .

The changes in this issue now allow editing {type: string, enum: …}! 🥳 (confirming what I wrote in #15 about #3456008).

That's what adapters are indeed for.

• At a technical level, #9 is trivial. It already works, and has basic test coverage since 📌 Centralize & standardize logic for constructing *PropSource objects + kernel test coverage Fixed .
• But providing a UI for adapters is very hard, let alone one that achieves the superb UX that XB aims for.

Please stop using the term "component edit form" — it's far too easy to confuse with \Drupal\experience_builder\Form\ComponentEditForm.

Precise steps to reproduce are missing. What was the precise filename of the image that caused the validation error?

Better yet: use that exact filename to add new test coverage to \Drupal\Tests\experience_builder\Kernel\PropSourceTest, to trigger the exact error message you were getting! 😄

Based on #9 and #13, I think we can change this issue to a documentation issue, where we document why this is not supported?

Per #13, this is considered not a code bug but misleading documentation?

I started with a test that gathers all unique SDC prop schemas. Then I started writing logic to automatically suggest the sane core-provided field type choice.

In doing so, I started treading on the territory of #3456008 — and I believe that we now should not do that issue anymore, at least not in its original scope: 📌 [PP-1] Add support for matching SDC prop shape: {type: string, enum: …} Postponed .

I am now thinking that not using a config entity type might actually be the only viable choice, because the config entity being proposed here only is viable if there is a good way to transform a given SDC prop schema into a PropShapeInput config entity ID — because that's how we could achieve sane dependencies.

The only reason that worked in the original proposal, is because HEAD does not yet support the {type: string, enum: …} use case, which is AFAICT widespread among SDCs. Once that is considered, the only way to generate a config entity ID is by hashing the enum.

The issue title + summary need a drastic update. See the new test class, which has 3 test methods that build on top of each other. I'll continue this MR tomorrow and will update this issue as well as 🌱 [META] Early phase back-end work coordination Active .

I suspect you forgot to mark this ?

I don't think it is likely that a {type: string, enum: …} SDC prop schema would be able to be supported by existing structured data (i.e. existing entity fields). IOW: a DynamicPropSource for them seems to be a rather edge case need.

But I do think it's a hard requirement that SDCs with such props are supported, so supporting StaticPropSources for them is crucial.

In working on 📌 Create new `PropShapeInput` config entity type Active , I realized that the "matching" infrastructure makes more sense for DynamicPropSource, but far less so for StaticPropSource. And in fact … I've got exactly this use case working there: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

🥳 Thanks for the update, @TravisCarden!

Thanks to the draft MR I pushed, with clear @todos, I think this is now actionable by novice contributors.