[PP-1] Editing code components as overrides, step 1

✨ Code Components as Block Overrides, step 1 Active is on track to being finished. I think the front-end work can begin on top of the current MR! 😊

Manual testing: getting started

When doing manual testing, I couldn't figure out how to create these from the UI. I was worried that I was doing something wrong. Then I was worried that xb_dev_js_blocks should not have been hidden in the UI (using package: Testing).

But then I discovered the reassuring statement by @balintbrews in the issue summary:

Start with a minimal implementation that doesn't allow creating overrides from the UI, but presents existing ones similar to code components, with reduced functionality. This will allow us to provide an initial set of overrides as config entities (e.g. shipped in a submodule).

All good!

Is it intentional that xb_dev_js_blocks's config is not enforced?

Note: uninstalling and reinstalling xb_dev_js_blocks does not cause the block-overriding code components to be recreated. That means that sites won't get updated config. This seems fine, but I wanted to double-check.

Manual testing: the menu block override has a JS error

I was able to edit the "Breadcrumb" and "Site branding" block overrides in the code component editor, and the preview updated live — awesome!

But for the "Navigation menu" one, the preview didn't render. It showed:

index.js:148 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading '__H')
    at l (index.js:148:19)
    at I (index.js:181:20)
    at B (index.js:168:9)
    at A.NavigationMenu [as constructor] (43d49346-52be-4dcb-aece-2d02a3de425c:5:29)
    at A.ve [as render] (index.js:665:14)
    at z (index.js:241:14)
    at oe (children.js:97:16)
    at z (index.js:267:13)
    at ye (render.js:42:2)
    at code-editor-preview.js:73:3

in the console.

But in @balintbrews's GIF in #5, it did work. 🤔

So I tried to see if there's anything off about this in either JavaScriptComponent::getExperimentalHardcodedBlockProps(), template_preprocess_menu__as_js_component(), or the test values at experimental/js-components-as-block-overrides/example-data/system_menu_block.json.

There's only one problem I found: the label slot. The test values specify it as:

  "slots": {
    "label": "<div>Main navigation</div>"
  }

Whereas the code renders it as:

        aria-label={label}

👆 markup clearly does not belong in there — an ARIA label should be assigned plain text, not markup.

So which is right, which is wrong? 🤔 Looking at template_preprocess_menu__as_js_component(), I find:

  $slots = [
    'label' => $block_variables['label'] ?: $block_variables['configuration']['label'],
  ];

That's clearly a plain-text label.

Which leads me to conclude that the very definition for system_menu_block is wrong — it doesn't have any slots.

Conclusion

I don't know what the original thinking is that led to "label" being a slot for menu blocks, so I defer to @effulgentsia and @balintbrews to address this in a follow-up. Meanwhile this MR brings this functionality alive, so merging with this known bug 👍

It was pretty cool to see my in-browser modified branding block appear on the live site 😄🤩

Assigning to Bálint for #menu-block-override-js-error in #7, which I bet (and hope) will be trivial for him 😄🤞

#7:

That's clearly a plain-text label.

Okay, so let's make it so! MR is incoming. Why this broke in your browser, and not in mine is a mystery, but I'm glad you caught this.

Huh! So I guess I did find the root cause! I actually tried doing exactly what you did here, but couldn't get it to work. Must've been a caching/wrong state problem.

Manually tested (on a fresh install), and it works:

🤩

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