[Svelte] Improve argTypes extraction

[xeho91]

Is your feature request related to a problem? Please describe.

The automatic argTypes extraction for Svelte since v8.4 is 🔥 🔥 🔥 🩷 🧡 !

This inspired me to understand how it works, so I did hack around it. In results, I've been inspired, and now I'm actively working on svelte-docgen package to extend and improve it.

Issues

This project aims to solve the following issues:

Mixed legacy on: with modern event handlers

Is it a common practice to extend types from svelte/elements where you can get types for event handlers.

Example component code:

<!-- Button.svelte -->
<script lang="ts">
  import type { HTMLButtonAttributes } from "svelte/elements";
  
  interface Props extends HTMLButtonAttributes {}
  let { children, ...rest }: Props = $props();
</script>

<button {...rest}>
  {@render children?.()}
</button>

Writing stories for this one example component will create arg table like this:

As you can notice, there are duplicates. Because svelte/elements provides deprecated event handlers types for v4 - for the backwards compatibility support.
In Svelte v5 there's been a breaking change—deprecated : in event handlers names.
So for example, on:click becomes onclick.

Improvements

The following list can help improve the Storybook DX for Svelte developers.

Note

I will continue to update this discussion thread whenever I can think of something else that is missing.

Component description & tags

It supports better the root HTML comment containting @component tag, which can provide description and tags (just like JSDoc) to provide another way to document without leaving the source *.svelte file component.

Recognition of legacy and modern components

In the extraction part of this project package, I was able to recognize when a component uses legacy syntax by providing a isLegacy prop.
This allows us to filter out legacy on:* props from types.

Support for snippets and its parameters

Some props can be snippets. If one is a snippet, does it provide parameters? If not, then we can also hack around it using createRawSnippet() and text input to provide static content. E.g., for children prop, which, AFAIK by following best practices, should not provide any parameters.

Bindable props

Some properties can be $bindable(). This project package(s) will recognize them. And their defaults too.

Extended props

I was able to create a feature that can recognize if a certain property is directly defined inside the *.svelte component file or extended from some interface defined in another module or package.

There are several ideas on how we can use this information:

1. Fold the table row with extended properties.
2. Add a "tag" to the table row to show extended property.

Event handlers

Props can be functions too. But how to recognize if this truly is an event handler? And properly typed with EventHandler or *EventHandler from "svelte/elements"? svelte-docgen package will provide this information via boolean flag - isEventHandler. It can be used for better categorization of props. Or perhaps improve the Actions (interactions addon) tab too?

---

Implementation plan

Because this project is still underway, I'd rather implement these changes gradually.
I'm still working alone on this project - and I'm looking for collaborators. So there's a hope I'll get some extra help to speed up the development.

Regardless, my idea is to start with:

1. Improving the current Vite's plugin - by creating a vite-plugin-svelte-docgen; look for data-related issues and fix them. In the meantime, feedback can be collected from users on how to display the data inside the arg tables. This is a win-win for both svelte-docgen and Storybook I believe.

   • feat(svelte): Use vite-plugin-svelte-docgen #29599

2. Then create the @svelte-docgen/server package, which was @shilman's idea.
   This would allow Storybook to stop using the aforementioned Vite's plugin, which slows down the build time.
   And inject logic into the Storybook server to run @svelte-docgen/server and allow Storybook UI to request specific component docgen data on demand. 👈 In this part, I will definitely require help from the core team, but we're not there yet. I have a small prototype (unpublished) where I created a server using Hono.