Draft: Resolve #3462310 "Component edit"

Closes #3462310

marked this merge request as draft

added 1 commit

• 384ff521 - Added select component and it's styling

Compare with previous version

I tried mapping the component drupal-select--xbxb and drupal-form-element-select--xbxb with the select element that i created but it does not load the component. It only load with select: SelectComponent,. The problem must be related to how hyperscriptify works.Is there something that i might be missing as a part of mapping the select element?

changed this line in version 4 of the diff

Had a discussion with @jessebaker regarding this that we need to use the select component form the Radix library.For now i have added the code with basic structure which can be further fine-tuned as we move forward.

added 1 commit

• d731b6f2 - Removed unwanted code

Compare with previous version

added 2 commits

• 75cbd76e - Wip for link component
• 6679c63f - Added drupal-select--xbxb for mapping

Compare with previous version

added 1 commit

• 4dd9794f - Removed linkElement

Compare with previous version

This does not renders the component that we create. But if i use select: SelectComponent then it loads the custom component that we created.

For any new components here, you also need to add a .twig file in experience_builder/templates/form

Look at the existing files there to see the naming conventions and what the file contents should be.

For now i have not added any options in the select list.

changed this line in version 7 of the diff

added 10 commits

• 4dd9794f...a8ead8ae - 3 commits from branch project:0.x
• 9dc9a871 - Rebasing
• 565848d9 - Added styling for input and label elements
• 7d2cc38a - Added select component and it's styling
• 3d262c85 - Removed unwanted code
• 0fd2b3ca - Wip for link component
• 4223f6bf - Added drupal-select--xbxb for mapping
• 7970bb62 - Removed linkElement

Compare with previous version

added 3 commits

• c851164f - Added custom select component close to figma designs
• 98e4653d - Prettier
• b42f607f - Added inline styles

Compare with previous version

added 1 commit

• eebf7a6f - Removed imports and fixed styleLint

Compare with previous version

added 2 commits

• fcfe3b7b - fixed styleLint
• 9a48986e - Added empty link element and mapped the element

Compare with previous version

added 18 commits

• 9a48986e...212b5fa3 - 3 commits from branch project:0.x
• 212b5fa3...2d70e8b4 - 5 earlier commits
• a4d593be - Added drupal-select--xbxb for mapping
• adc142ab - Removed linkElement
• fc006002 - Added custom select component close to figma designs
• 87b61640 - Prettier
• 40f1dba1 - Added inline styles
• 802237c9 - Removed imports and fixed styleLint
• 2bbc054a - fixed styleLint
• 53c4abff - Added empty link element and mapped the element
• c588ac76 - Renamed link--xbxb to links--xbxb
• d37a1ad4 - Stylelint

Compare with previous version

added 1 commit

• 59f3a153 - Conditionally rendered link element inside input element

Compare with previous version

This won't work as we are not processing the link element seperately but it's processed as a part of input.tsx where i have added a if condition that if props.attributes.type === 'url' then return a distinguishing markup for link element. We can see that in the DummyPropsForm.

I am not sure what and how we need to distinguish between the link and input component.

When you reference DummyPropsForm can you also mention what component is being edited? The contents can be a vastly different depending on the component type so not knowing it makes it very difficult to know what is being referenced.

I'm also not entirely sure what is meant by but it's processed as a part of input.ts but if that but as mentioned in another comment, Links and inputs are separate templates, you do not need to account for one in the other. The input template renders children, and links can be one of those children, but it doesn't need to do anything special for it. This may be an issue of not having the props fully set up in links--xbxb-html.twig

This is a workaround so that we can distinguish the Link elements with the default input element. This is also the reason for the test fails i guess.

In Twig, the input links are fully separate templates that are not codependent in any way, and the same can happen (and should happen) in JSX equivalents.

templates/form/links--xbxb.html.twig i have added links because we have links.html.twig as the templates.

Based on the variables list in links.html.twig, it seems like there should be more depth to this configuration. This determines what gets sent as props, and what data type is expected. For example within links there are sub-properties that will likely be different data types `* - links: Links to be output.

• Each link will have the following elements:
• • link: (optional) A render array that returns a link. See

• template_preprocess_links() for details how it is generated.

• • text: The link text.
• • attributes: HTML attributes for the list item element.
• • text_attributes: (optional) HTML attributes for the span element if no

• 'url' was supplied.`

If you're unsure what props to set up, a breakpoint at the end of semi_coupled_theme can help too. return $renderer->render($element);

Once the doubt asked in !162 (comment 358657) gets clarified we can add the markup here to render the link elements.

This isn't typescript or syntax that supports | syntax. This is information passed to _semi_coupled_collect_props. Looking at the logic in _semi_coupled_collect_props can help you determine what type to use.

I think we're using stylesheets over inline styles aside from special circumstances

Where is this icon property coming from? That doesn't seem to match the template variables documented in the twig version ` * Each link will have the following elements:

• • link: (optional) A render array that returns a link. See

• template_preprocess_links() for details how it is generated.

• • text: The link text.
• • attributes: HTML attributes for the list item element.
• • text_attributes: (optional) HTML attributes for the span element if no

• 'url' was supplied.`

If you look at the existing components, you'll notice the export is wrapped in InputBehaviors

For example export default inputBehaviors(Input); this is what makes it possible to manage values at the form level instead of the component level and update redux without having to add handlers to every new component.

Values aren't managed on a per-component basis, they are instead wrapped by InputBehaviors. See the existing components for how this is done.

If there is a specific reason for component level state then it can ALSO be here, but we need to loop into the onChange setup in inputBehaviors

What is this renderOptions variable - maybe a Radix thing?

I think it would be great to leverage design tokens from Radix Themes in the form of CSS variables. A few examples:

• Instead of defining the paddings or the gap in pixels, let's use space scale tokens;
• The border radius can use the radius scale;
• Any color should probably use a color token.

We may need to customize the Theme component to tweak some of the values. I think it's also a good idea to keep in mind that if we end up with a lot of CSS overrides, we should probably be using the unstyled Radix Primitive rather than the component from Radix Theme. Also when adding wrappers only for layout, let's use Box, Flex etc, so we can avoid adding paddings, margin etc. with custom CSS.

Closing this in favor of !188 (merged).

closed