Object type prop support for React Dynamic code snippet

[andreevgy]

Hello Figma team! Thanks for the Code Connect tool. We are currently setting it up for new Design System in our company to help developers and LLMs to better understand how components work in code. While Dynamic Code Snippets solve most of the cases for us, I have one feature request related to the mapping of object type props. I know this was already discussed, but I did not see my particular case, so wanted to bring it up.

Use case:
Imagine Checkbox component that can conditionally render Hint component. In our Design System we follow props composition approach where you can pass props of underlying component to the parent component. Looks something like this when implemented (all non-related props are omitted here and in rest of request):

const Checkbox = ({ hint, ...rest }) => 
  <div>
    {hint && <Hint {...hint} />}
    {/* rest of the component */}
  </div>

And when implemented it can be used like this:
With hint: <Checkbox hint={{ children: "Hint text" }} />
Without hint: <Checkbox />

In Figma, there is a hint boolean that controls if Hint component is rendered and (consequentially) if this components props are available for editing. I tried all three variants in the spoiler below and none of them worked:

Dynamic Code Snippets generating incorrect code

In nested properties example, Figma docs suggest using figma.nestedProperties with figma.boolean. While it works well with generic values, it fails when we need to pass a whole object as a prop.

We want hint: true case to generate snippet like this:
<Checkbox hint={{ children: "some text" }} />
While hint: false have hint prop in code completely omitted:
<Checkbox />
We can try to approach it in several ways using figma.boolean.
First option:

figma.connect(Checkbox, FIGMA_URL, {
  props: {
    hint: figma.boolean("hint", {
      true: figma.nestedProps("Hint", {
        children: figma.string("hint")
      }),
      false: undefined
    }),
  },
  example: (props) => (
    <Checkbox
      hint={props.hint}
    />
  ),
});

This example won’t work because of Figma Code Connect limitations. Example function here is just a template for Code Connect to put variables in, and it does not evaluate any JS inside of it. While it has access to the props.hint object, it does not know how to put the whole object in the snippet, resulting in next example generated:
<Checkbox />

Second option:
Knowing that Figma cannot put object into snippet, you might want to try something like this:

figma.connect(Checkbox, FIGMA_URL, {
  props: {
    hint: figma.boolean("hint", {
      true: figma.nestedProps("Hint", {
        children: figma.string("hint")
      }),
      false: undefined
    }),
  },
  example: (props) => (
    <Checkbox
      hint={{ children: props.hint?.children }}
    />
  ),
});

This example will work correct for the hint: true case and it will generate something like this:
<Checkbox hint={{ children: "some text" }} />
However, for the hint: false case, it will generate this snippet:
<Checkbox hint={{ children: undefined }} />
Which is not what we want.

Third version:
At the end you might want to try something like this:

figma.connect(Checkbox, FIGMA_URL, {
  props: {
    hint: figma.boolean("hint", {
      true: figma.nestedProps("Hint", {
        children: figma.string("hint")
      }),
      false: undefined
    }),
  },
  example: (props) => (
    <Checkbox
      hint={ props.hint ? { children: props.hint?.children } : undefined }
    />
  ),
});

But unfortunately, (since Figma does not evaluate any JS), it will only generate snippet like this for hint: true
<Checkbox hint={undefined ? { children: “some text” } : undefined}
and like this for hint: false:
<Checkbox hint={undefined ? { children: undefined } undefined} />

Considering all the options above does not work, the only option is to use variant:

// Variant: without hint
figma.connect(Checkbox, FIGMA_URL, {
  variant: { hint: false },
  props: {...},
  example: (props) => (
    <Checkbox ... />
  ),
});
// Variant: with hint
figma.connect(Checkbox, FIGMA_URL, {
  variant: { hint: true },
  props: {
    ...
    hint: figma.nestedProps("Hint", {
      text: figma.string("hint"),
    }),
  },
  example: (props) => (
    <Checkbox ...
      hint={{
        children: props.hint.text,
      }}
    />
  ),
});

This generates correct snippets and solves the problem for components that have only one of such nested components.

Problem:
We have components like FormField that has multiple nested components. variant approach does not scale well for such components because the number of variants grows exponentially with every new conditionally rendered component added.

Component:

const FormField = ({ hint, validationMessage ...rest }) => 
  <div>
    {hint && <Hint {...hint} />}
    {/* rest of the component */}
    {validationMessage && <ValidationMessage {...validationMessage} />}
  </div>

Code Connect file:

figma.connect(FormField, FIGMA_URL, {
  variant: {hint: false, validation: "none"},
  ...
});
figma.connect(FormField, FIGMA_URL, {
  variant: {hint: true, validation: "none"},
  ...
});
figma.connect(FormField, FIGMA_URL, {
  variant: {hint: false, validation: "invalid"},
  ...
});
figma.connect(FormField, FIGMA_URL, {
  variant: {hint: true, validation: "invalid"},
  ...
});
figma.connect(FormField, FIGMA_URL, {
  variant: {hint: false, validation: "valid"},
  ...
});
figma.connect(FormField, FIGMA_URL, {
  variant: {hint: true, validation: "valid"},
  ...
});

While template files solve the issue, it's really cumbersome to write them only for such simple conditional cases.

Desired behaviour:
Ideally, we would have preferred objects to be rendered in the snippets correctly. Below is the example of desired behaviour with Checkbox component.

Code Connect file:

figma.connect(Checkbox, FIGMA_URL, {
  props: {
    hint: figma.boolean("hint", {
      true: figma.nestedProps("Hint", {
        children: figma.string("hint")
      }),
      false: undefined
    }),
  },
  example: (props) => (
    <Checkbox
      hint={props.hint}
    />
  ),
});

hint: true case:

<Checkbox hint={{ children: "text from figma" }} />

hint: false case:

 <Checkbox />

Sorry for the long post, just wanted to make sure we tried all other options and explain why it would be valuable to have it. Happy to discuss further.

[slees-figma]

Hey @andreevgy! Thanks for detailed report. This looks like and edge case of the API where it isn't possible to achieve exactly what you're looking for. You're right that the way to achieve this today would be using variant restrictions which aren't feasible for your use case.

Sharing in case this is of interest - we also support a "parserless" Code Connect setup where you write your templates as strings rather than using figma.* code. You lose some benefits of parsers like type safety + intellisense, but as the templates are plain JS you're free to add any transformations you like in code: https://developers.figma.com/docs/code-connect/no-parser/ - would be curious to hear any feedback you have on this!

[andreevgy]

Thanks @slees-figma! We are actually using "parserless" option following the guide you shared for such complex cases, but it has its own caveats:

1. Since it's fairly "manual", we kept repeating same code in each template file. For example, some functions to extract props from underlying layers. Since there can be no imports other than "figma", we got around it by creating a build step before publishing that inlines imported functions into the file. Is it an intended way or is there something that I am missing?
2. Some of these functions rely on executeTemplate().metadata.__props to make sure we don't need to change all template files if underlying component props change. It looks like these values are for internal use only and I expected that they might break without a notice.

Ultimately, points above increase the friction and maintenance costs for the whole DS since process of writing these template files is quite low-level.

Don't know if there are any plans to change anything about it, but that's just some feedback I have working with our case.