Block Added to Incorrect Location and "Add Block" UI Persists After Addition (QWIK SDK)

Visual Editor Help
,
1

We’re attempting to replicate the Tabs visual editing example from the Builder.io documentation, specifically from the section on adding editable regions to custom components.

Our goal is to translate this React example to Qwik. (which is simply changing to a signal). Both examples use the gen 2 SDK.

Here is a video showing the problem.

Steps Taken

  1. We copied the React Gen 2 (or Gen 1) tabs example verbatim from the documentation.
  2. We then adapted it for Qwik by:
    • Changing useState to useSignal
    • Adding .value to the end of each signal reference

Current Issues

After implementing these changes, we’re encountering two main problems:

  1. Incorrect Block Placement: When adding a new block, it appears at the end of the page instead of under the correct parent component.

  2. Persistent “Add Block” UI: The “Add Block” UI continues to display even after adding a block, suggesting that the new block isn’t being properly registered.

2

Hello @jackshelton,

Thank you for reaching out and sharing the details of the issue you’re encountering while translating the React example to Qwik. I appreciate the steps you’ve taken so far, and based on your description, I believe the following solution may resolve the problems you’re facing.

We’ve tested the Custom Tabs component in Qwik using GEN 2 SDK(sdk-qwik) , and it seems to be working as expected. Below is the code for the Tabs component, which you can try implementing in your project:

import { component$, $, useSignal } from '@builder.io/qwik';
import { BuilderBlock, Blocks } from '@builder.io/sdk-qwik';

type Tab = {
  label: string;
  content: BuilderBlock[];
};

type TabsProps = {
  tabs: Tab[];
  builderBlock?: {
    id: string;
  };
};

export const Tabs = component$((props: TabsProps) => {
  const activeTab = useSignal(0);

  const handleTabClick = $(index => {
    activeTab.value = index;
  });

  return (
    <>
      <div
        style={{
          display: 'flex',
          overflow: 'auto',
        }}
      >
        {props.tabs.map((item, index) => (
          <span
            key={index}
            style={{
              padding: '20px',
              color: activeTab.value === index ? 'white' : '#ccc',
            }}
            onClick$={() => handleTabClick(index)}
          >
            {item.label}
          </span>
        ))}
      </div>
      {props.tabs.length > 0 && props.builderBlock && (
        <Blocks
          parent={props.builderBlock.id}
          path={`component.options.tabs.${activeTab.value}.content`}
          blocks={props.tabs[activeTab.value].content}
        />
      )}
    </>
  );
});

Additionally, here’s the registration code for the Tabs component:

 {
    component: Tabs,
    name: 'Tabs',
    canHaveChildren: true,
    shouldReceiveBuilderProps: {
      builderBlock: true,
    },
    inputs: [
      {
        name: 'tabs',
        type: 'list',
        subFields: [
          {
            name: 'label',
            type: 'text',
            defaultValue: 'New tab',
          },
          {
            name: 'content',
            type: 'uiBlocks',
            defaultValue: [],
          },
        ],
        defaultValue: [
          {
            label: 'Tab 1',
            content: [],
          },
        ],
      },
    ],
  }

Loom:

SDK used: @builder.io/sdk-qwik": "^0.16.13

Please give this a try and let us know if the issue persists. If you encounter any further difficulties or have any questions, we’ll be happy to assist you further.

Looking forward to your feedback!

Best regards,

3

Hey Manish!

Looks like this has definitely improved. Unfortunately I’m still running into two issues with this example from the docs:

  1. There is a long synchronization period, where the preview needs to be refreshed in order to see the data visually updated.
  2. To update fields like the tabs title, the preview needs to be refreshed in order to see the change

Both issues same related here.

Let me know if this video showcasing the problem helps:

Happy to help push this further along, as I think it plays a big part in the editing experience of using Builder with Qwik.

4

Hello @jackshelton,

I wanted to provide you with an update regarding the ongoing issue we’re discussing with our team. Specifically, we are addressing the problem where the editor does not reflect changes made to sub-fields of the input type list.

I will keep you informed as soon as we make any progress.

Best regards,