Vue: Improve generated code snippets

[larsrickert]

relates to #26691

the PR is targeted to the main branch, is this correct or should it be next?

What I did

I created a new improved Vue source code generator that has several improvements compared to the current one:

• use shorthand for truthy booleans: my-prop instead of :my-prop="true"
• Support double quoted strings like my-prop='"I am double quoted"', useful if e.g. passing SVG icon content as props
• use correct source code for arrays (:my-props="['a', 'b']"), currently they are generated as object (:my-prop="{0:'a',1: 'b'}") which is incorrect
• do not render "undefined / null" values
• support for BigInt in props and slots
• support for Symbol in props
• do not add unnecessary <template #default> for default slot without bindings

The most important feature of this PR: Support source code for slots that use VNodes / custom Vue components:
Currently you can already use Vue's h() function to pass custom Vue components or HTML content to slots which are then rendered in the Story. This is very useful since you don't need to use a custom render function then which uses a template string (no type-safety, intellisense etc.).

Check the below example of a nav bar that we are currently working on for the onyx design system where the nav items are passed as slot.

However, the generated source code previously looked like this which is unusable:

With the new source code generator, all VNodes including nested children are generated as expected like this:

As reference, here is the Story source for the above example:

export const Default = {
  args: {
    logoUrl: "/onyx-logo.svg",
    appName: "App name",
    default: () => [
      h(OnyxNavItem, { label: "Item", href: "/", active: true }),
      h(
        OnyxNavItem,
        {
          label: "Item",
          href: "/test",
          options: [
            { label: "Nested item 1", href: "#" },
            { label: "Nested item 2", href: "#" },
            { label: "Nested item 3", href: "#" },
          ],
        },
        () => ["Item", h(OnyxBadge, { dot: true, color: "warning" })],
      ),
      h(OnyxNavItem, { label: "Item", href: "https://onyx.schwarz" }),
    ],
  },
} satisfies Story;

*Current limitations / open TODOs (some could be done in follow up PRs)*:

• check with Storybook maintainers how to release the new decorator. Maybe as opt-in parameter so its not a breaking change for Storybook 8
• Generate source code for slots with bindings (currently such stories will throw an error)
• Check if function properties and events should be generated, e.g. :my-prop="() => 42" or @click="() => ({})"
• support <script lang="ts" setup> and e.g. automatically place complex values like objects and arrays there instead of inlining them in <template>

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

1. Run a sandbox for template, e.g. yarn task --task sandbox --start-from auto --template vue3-vite/default-ts
2. Open Storybook in your browser
3. Access any story and check the generated source code
4. Switch back to the previous source code generator by opening code/renderers/vue3/src/entry-preview-docs.ts and changing the codeSnippetType to legacy
5. Run code code && yarn build vue3
6. Restart Storybook
7. Check the same stories again and compare the difference in the generated source code

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit a7d29c3. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 2 targets

• nx affected -t check -c production --parallel=7
• nx run-many -t build -c production --parallel=3

---

Sent with 💌 from NxCloud.

[chakAs3]

Great job, @larsrickert! I had some old TODOs regarding slots because the generated code wasn't handling edge cases properly.

[chakAs3]

I appreciate your approach of preserving the previous code as legacy. However, it seems like your new code could be integrated as an improvement. Could you clarify why it's necessary to retain the legacy code since no major features appear to be overridden?

[larsrickert]

I think my point was about the <script setup> feature. Currently there is an opt-in parameter the user can set to move props to the <script> section.

My goal would be to automatically move complex props (object, arrays and functions) to the <script> section and keep primitive props (string, Boolean, number) inside the .

This is not breaking change on its own but it could break code snippets of projects that use custom source code transformers to e.g. add import statements etc. But if you say that’s not considered a breaking change for Storybook I am totally finde since it’s probably a rare edge case.

[kasperpeulen]

@larsrickert Should be next indeed. I added patch:yes, so that it will automatically patched back to main as well.

Let me now when you are finished with this!