Code Components as Block Overrides, step 1

Adding some filtering capabilities to our /xb/api/config/js_component endpoint could be nice, so it can return config entities with empty vs. non-empty override properties, helping us display two distinct lists on the UI. With that said, we can easily separate the items on the frontend, so this can happen in a follow-up.

Here's an initial patch (yeah, I know, MRs are better, but old habits die hard) with system_menu_block implemented. I'll work on breadcrumb, site branding, and page title next.

This includes page_title and system_branding. Still need to do breadcrumb.

Note, if you're testing the wip patch, make sure to:

• Install the xb_dev_js_blocks module (included in the patch), since that's what provides the default JS component entities.
• Within the theme settings, click "Use Experience Builder for page templates in this theme.", since the JS component entities only override rendering of blocks that are rendered via XB dynamic components, not blocks that are rendered via Block UI entities.

This adds the breadcrumb block, so now this has all 4 desired for the initial scope.

Thanks for the patches, @effulgentsia! I created an MR and verified the functionality. It works beautifully! I added the components to our working repository for the initial code components.

I also added testing steps to the issue summary. In addition to #8 ✨ Code Components as Block Overrides, step 1 Active , we need to re-run the build to get the necessary change to our bundled hydration library. I learned that the hard way. 😛 I saw your change there initially, but by the time I started testing, I forgot about it, then I thought we may have never tested our astro_island element with actual props, so I got into debugging. Once I found the relevant part in Astro, I realized what I forgot. 🙃 In any case, this gave me more confidence in our implementation, so it was a good adventure.

wim leers → made their first commit to this issue’s fork.

It works!

I've got it working locally using the steps in #8. I manually modified the "admin" menu block Component config entity to expand all levels, and … that does work:

😊

Concerns/initial review

Picking up where @effulgentsia left off. He handed it over to me in the past hour, and he answered my 2 most crucial questions:

1. https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...
2. https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...

Next

Self-assigning to get this MR:

• to green
• to explicitly isolate/annotate the highly experimental bits that this introduces.

This blocks ✨ [PP-1] Editing code components as overrides, step 1 Postponed .

Finished adding the critical server-side test coverage:

1. at the full page rendering level: https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...
2. at the component tree rendering level: https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...

This test coverage revealed some flaws in the existing infrastructure:

1. the BlockComponent::renderComponent() logic that dynamically switches to use the block-overriding JavaScriptComponent lacks cacheability information: https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...
2. XbConfigOverrides (introduced only days ago, in 📌 Code Components should render with their auto-saved state(if any) when rendered in the XB UI Active ), is bubbling cacheability incorrectly: https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...
3. the existing access control for JavaScriptComponent's @todos are actively getting in the way: they prevent the integration test from working — but that's for 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active to fix.

I'm not proficient at writing Cypress e2e tests, so leaving to somebody else, so I can switch gears to other pressing matters. I defer to @effulgentsia and @balintbrews to decide whether this is commit-blocking or not. 💡 They decided that it's not necessary, because they both confirmed this is all highly experimental and likely to change 👍

Next up:

• on 10.4.x this fails with You have requested a non-existent service "plugin.manager.condition". — can somebody please investigate that? 🙏
• docs
• @balintbrews or @effulgentsia to confirm https://git.drupalcode.org/project/experience_builder/-/merge_requests/6... is correct
• @effulgentsia to review the test coverage I added

@balintbrews or @effulgentsia to confirm 135ac01 is correct

Yes, that change is correct. Though as a side note, I'm curious under what conditions it's reachable. Are default slots a thing in SDCs? I only see examples of named slots, or did I not search thoroughly enough?

Thanks for adding those tests, Wim. They look great. Back to needs work for the rest of #19 (docs + the error on 10.4.x).

#20: IDK when that is reachable — but our kernel tests surely were reaching it!

#21: yay!

The 2 last bullets of #19 are complete thanks to @effulgentsia, assigning to @longwave for

• on 10.4.x this fails with You have requested a non-existent service "plugin.manager.condition". — can somebody please investigate that? 🙏
• docs

This should also get an entry in CODEOWNERS, under the

# ⚠️
# ⚠️ Highly experimental new concepts ⚠️
# ⚠️

section.

I think this is OK to land as highly experimental and have added even more comments to denote this. I am not sure that mapping each block plugin that might want to become a JS component is sustainable; I have concerns about both discoverability for developers and extensibility by contrib if we do continue with this solution. But, I don't have a better idea right now, and this unblocks the feature to see if it is at least workable and understandable by XB users who are experimenting with JS components.

Looking at test failures.

That should be the last of the test failures.

Looks great!

1. Added missing "invalidate (render) cached block component instances when an overriding code component instance is saved" — which @longwave pointed out: tests (fails) + fix
2. Added missing internal HTTP API test coverage to ensure the client can actually set block_override! Turns out it couldn't 😅 It was missing a one-liner. That'd have been a frustrating discovery for @balintbrews in ✨ [PP-1] Editing code components as overrides, step 1 Postponed !

I think there's plenty of warnings to not risk this ossifying as-is. I agree with @longwave's concerns, but … I mostly admire the very clever solution @effulgentsia demonstrated here 🤯

Automatically closed - issue fixed for 2 weeks with no activity.