[Meta] Plan for in-browser code components

#6++ — I think all that is worth capturing in docs/ 😊🤓 Perhaps in docs/components.md?

A new challenge apepared: https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... for #3498889: ComponentSource plugin for code components.

Remember that the way XB's UI is able to determine which parts of the (server-side rendered!) preview markup correspond to which components and slots is powered by HTML comments. Quoting /ui/tests/unit/function-utils.cy.js, it looks like this:

 <!-- xb-start-ad3eff8e-2180-4be1-a60f-df3f2c5ac393 --><div data-component-id="experience_builder:two_column" data-xb-uuid="ad3eff8e-2180-4be1-a60f-df3f2c5ac393">
          <div class="column-one width-25" data-xb-slot-id="ad3eff8e-2180-4be1-a60f-df3f2c5ac393/column_one">
            <!-- xb-slot-start-ad3eff8e-2180-4be1-a60f-df3f2c5ac393/column_one --><!-- xb-start-9bee944d-a92d-42b9-a0ae-abae0080cdfa --><h1 data-component-id="experience_builder:heading" class="primary" data-xb-uuid="9bee944d-a92d-42b9-a0ae-abae0080cdfa">A heading element</h1>
<!-- xb-end-9bee944d-a92d-42b9-a0ae-abae0080cdfa --><!-- xb-slot-end-ad3eff8e-2180-4be1-a60f-df3f2c5ac393/column_one -->
        </div>

          <div class="column-two width-75" data-xb-slot-id="ad3eff8e-2180-4be1-a60f-df3f2c5ac393/column_two">
            <!-- xb-slot-start-ad3eff8e-2180-4be1-a60f-df3f2c5ac393/column_two --><p>This is column 2 content</p><!-- xb-slot-end-ad3eff8e-2180-4be1-a60f-df3f2c5ac393/column_two -->
        </div>
    </div>
<!-- xb-end-ad3eff8e-2180-4be1-a60f-df3f2c5ac393 -->

(Note the xb-start- and xb-slot-start-.)

And like this:

                            <!-- xb-start-fce5e0e3-175f-48b5-a62c-176dbc5f3e91 -->
                            <div data-component-id="experience_builder:my-hero"
                                 class="my-hero__container">
                                <h1 class="my-hero__heading">
                                    <!-- xb-prop-start-fce5e0e3-175f-48b5-a62c-176dbc5f3e91/heading -->
                                    There goes my hero
                                    <!-- xb-prop-end-fce5e0e3-175f-48b5-a62c-176dbc5f3e91/heading --></h1>

(Note the xb-start- and xb-prop-start-.)

While editing components and placing them in slots requires only the annotations from the first kind (component + slot), SDC-sourced XB components actually already have their props annotated too, which will enable us to provide (visual and otherwise) affordances connecting inputs in the ComponentInputsForm form to very specific bits of markup in the preview. We're just not doing that yet. That work landed in preparation for #3453690: [META] Real-time preview: supporting back-end infrastructure.
Because it's not yet actively used in XB, I explicitly +1'd not holding up #3498889 for that.

@larowlan pointed out in https://git.drupalcode.org/project/experience_builder/-/merge_requests/5... that we can keep generating xb-start- and xb-slot-start- HTML comments, but that xb-prop-start- is not actually possible. How did the folks working on the PoC envision supporting that?

AFAICT the closest issue to that 👆 is #3500081: Editing components sourced as code components. But I figured I'd post on the meta/plan issue to avoid potentially derailing/blurring the scopes of #3500081. 😊

Adding #3502893: Create a badge element for navigating out of the code editor in the top bar to the must have list, after discussing with @balintbrews

xb-prop-start- is not actually possible

Not in scope for 0.3, but if we want to support this at some point, I think we'd need to do it as part of the source_js -> compiled_js compilation. For example, perhaps prior to compiling with SWC, we first pass the source JS through Babylon to find where props are being output and inject the HTML comments into there.

xb-prop-start- is not actually possible

My understanding is that this was added to support a future state where we didn't need a round trip to the server to update the preview.

With code components, we don't do any server side rendering so I don't think we need to worry about props - we will already have client side updates right?

Yes to #13 but in addition there's also the desired future state where if, for example you click within the canvas on the part of the component where a prop is rendered, the ComponentInputsForm opens with focus on the corresponding widget.

Thanks, both of those make sense. I forgot about in place editing 👍️

adding a space just to update the issue summary issue statuses since we finished a sprint, is that how it's done?

Incredible progress the past 2 weeks! 🤩 Tested what landed last night, and found 2 problems, the first of which is definitely minor:

• #3503544: Re-GETting the list is unnecessary: faster client, less server load
• #3503547: Display validation errors in dialogs that create sections

I think the first one is a NICE-TO-HAVE, the second one a MUST-HAVE SHOULD-HAVE (given time constraints).

#3500386: Code Components should render with their auto-saved state (if any) when rendered in the XB UI is missing from the issue summary. Is that intentional?

It also doesn't account for the fact that auto-saves are not guaranteed to be in a working state. Which means that once #3500386: Code Components should render with their auto-saved state (if any) when rendered in the XB UI is done, a temporarily broken code component could break all XB previews.

(For example: modifying the code to not output a slot, while the metadata does say that that slot exists.)

How would this break? Wouldn't it just not output the slot?

Yes. And if 90% of the component tree happens to be in that slot, the result will be that suddenly all XB previews seem to be very broken because the majority of the content would be missing 😭😄

A different kind of breakage would be: the JS throws an error early on, causing it to not render anything at all. That might result in JS components having the same breakage as seen in the screenshot at #3485878: Server-rendered component instances should NEVER result in a user-facing error, should fall back to a meaningful error instead (+ log), but there we know we can prevent that from ever happening for SDCs — we just haven't done it yet.

The breakage in #3485878: Server-rendered component instances should NEVER result in a user-facing error, should fall back to a meaningful error instead (+ log) is due to invalid component inputs, which can happen for any component type. The concern I'm raising in #20 and here is that for auto-saved code components there is a completely new failure mode: invalid component logic. And #3500386: Code Components should render with their auto-saved state (if any) when rendered in the XB UI would cause that problem to instantly "spread" to all places where that code component is being used! 🧟

Added #3508694: Permissions for XB config entity types.

Shouldn't #3505993: Code Components as Block Overrides, step 1 be in here too?

Reflecting that … ALL MUST-HAVES ARE DONE! 🤯🥳

@lauriii and I realized an hour ago that we need a code component sibling of #3453690: [META] Real-time preview: supporting back-end infrastructure.

@mayur-sose created #3514035: Creating multiple components with same label causes error: entity with ID already exists, which is a subset of #3503547: Display validation errors in dialogs that create sections.

With #3518182: [Plan] First-party code component imports being the next important feature for in-browser code components … @balintbrews can we close this? 🤞

Re #26, I opened #3514910: Refinements of real-time preview for props changes of JS components.

Re #28, this issue still has child issues for CLI tooling, but maybe we should open a new Meta/Plan issue for that and move those to there? Especially since this issue even has "in-browser" in its title :)

maybe we should open a new Meta/Plan issue for that and move those to there? Especially since this issue even has "in-browser" in its title :)

💯 This! 😄