[RFC]: Typesafe CSF factories

[kasperpeulen]

RFC: Typesafe CSF factories

Storybook's current syntax lacks the modern, developer-friendly features that competing tools offer, such as autocomplete and discoverability. Developers need to remember Storybook-specific jargon, which creates a high cognitive load. Other tools in the ecosystem have standardized the factory pattern (e.g. defineConfig), which offers intuitive autocomplete and suggestions that make the experience seamless. Without these features, users struggle to configure addons correctly and may overlook valuable features Storybook offers.

Try it out today!

You can try out this new experimental CSF factory syntax in your React projects (more renderers will be supported later) today.

1. Make sure you are upgraded to storybook 9:

npx storybook@latest upgrade

2. Install the latest alpha release:

npx storybook@next upgrade

3. If you are using CSF2, migrate first to CSF3:

npx storybook migrate csf-2-to-3 --glob="**/*.stories.tsx" --parser=tsx

4. Migrate your stories to CSF factories automatically (or read the manual upgrade instructions):

npx storybook automigrate csf-factories

5. If you are using the vitest addon, you can remove your .storybook/vitest.setup.ts file. The setProjectAnnotations call is done automatically with CSF factories.

Manual upgrade instructions

Update your preview config file

The ability for an addon to provide annotation types (parameters, globals, etc.) is new and not all addons support it yet.

If an addon provides annotations (i.e. it distributes a ./preview export), it can be imported in two ways:

1. For official Storybook addons, you import the default export:
   import addonName from '@storybook/addon-name'

2. For community addons, you should import the entire module and access the addon from there:
   import * as addonName from 'community-addon-name/preview'

// Replace your-framework with the framework you are using (e.g., react-vite, nextjs, nextjs-vite)
+ import { definePreview } from '@storybook/your-framework';
- import type { Preview } from '@storybook/your-framework';
// 👇 Import the addons you are using
+ import addonA11y from '@storybook/addon-a11y';
+ import * as communityAddon from 'community-addon-name/preview'
 
+ export default definePreview({
- export const preview: Preview = {
    // ...current config
    // 👇 Add your addons here
+   addons: [addonA11y(), communityAddon],
+ });
- };
- export default preview;

Update your story files

Story files have been updated for improved usability. With the new format:

• Import the preview construct from the Storybook preview file
• The meta object is now created via the preview.meta function and does not have to be exported as a default export
• Stories are now created from the meta object, via the meta.story function

+ import preview from '#.storybook/preview';
- import type { Meta, StoryObj } from '@storybook/your-framework';

import { Button } from './Button';

+ const meta = preview.meta({
- const meta = {
    // ...current meta
+ });
- } satisfies Meta<typeof Button>;
- export default meta;

- type Story = StoryObj<typeof meta>;

+ export const Primary = meta.story({
- export const Primary: Story = {
    // ...current story
+ });
- };

Note that importing or manually applying any type to the meta or stories is no longer necessary. Thanks to the factory function pattern, the types are now inferred automatically.

Reusing story properties

If you want to reuse story properties from another story, you can use the extend API:

// ...rest of file

+ export const Primary = meta.story({
- export const Primary: Story = {
    args: { primary: true },
+ });
- };

+ export const PrimaryDisabled = Primary.extend({
- export const PrimaryDisabled: Story = {
    args: {
-     ...Primary.args,
      disabled: true,
    }
+ });
- };

Important

All sections marked with ✅ are implemented in this canary.
At this time, only React projects are supported.

Introducing CSF factories ✅

Writing a type-safe CSF3 story typically involves significant boilerplate. Here's an example of a standard CSF3 story for a Button component:

// Button.stories.ts
import type { Meta, StoryObj } from '@storybook/react';
import { Button } from './Button';

const meta = { component: Button } satisfies Meta<typeof Button>;
 
export default meta;

type Story = StoryObj<typeof meta>;
 
export const Primary: Story = {
  args: {
    primary: true,
    label: 'Button',
  },
};

To streamline this process, we can introduce factories that require no extra type annotations for type safety. Here's how the Button story would look using factories:

import preview from '#.storybook/preview';
import { Button } from './Button';

const meta = preview.meta({ component: Button });

export const Primary = meta.story({
  args: {
    primary: true,
    label: 'Button',
  },
});

This approach reduces the need for explicit type declarations and manual repetitive code, minimizing the chances of errors. It makes the story definitions more concise and easier to understand.

The preview file ✅

The preview file is central to configuring Storybook's behavior and addons. Here's a .storybook/preview.ts file using the proposed definePreview factory:

// .storybook/preview.ts
import { definePreview } from '@storybook/nextjs';
import addonDocs from '@storybook/addon-docs';
import addonA11y from '@storybook/addon-a11y';

export default definePreview({
  addons: [addonDocs(), addonA11y()],
})

Importantly, by specifying addons here, their types will be available throughout your project, enabling autocompletion and type checking.

You will import the result of this function, preview, in your story files to define the component meta.

import { definePreview } from '@storybook/your-framework';
import addonDocs from '@storybook/addon-docs';
import addonA11y from '@storybook/addon-a11y';

export default definePreview({
  // 👇 Add your addons here
  addons: [addonDocs(), addonA11y()],
  parameters: {
    // type-safe!
    a11y: {
      options: { xpath: true },
    },
  },
});

The preview configuration will be automatically updated to reference the necessary addons when installing an addon via npx storybook add <addon-name>. In the future we will do a runtime check when running storybook dev, making sure that the addons defined in main.ts and preview.ts always stay in sync.

The preview.meta factory ✅

The meta function on the preview object is used to define the metadata for your stories. It accepts an object containing the component, title, parameters, and other story properties.

import preview from '#.storybook/preview';

import { Button } from './Button';

const meta = preview.meta({
  component: Button,
  parameters: {
    // type-safe and autocompleted!
    layout: 'centered',
  }
});

Note: While you can use relative imports for the preview file, we recommend adopting this standard-based absolute import convention, popularized by Kent C. Dodds. Learn more about this convention. We provide the option to automatically set this up when migrating with npx storybook automigrate csf-factories.

The meta.story factory ✅

Finally, the story factory on the meta object defines the stories. This function accepts an object containing the name, args, parameters and other story properties.

const meta = preview.meta({ /* ... */ });

export const Primary = meta.story({
  args: {
    // type-safe!
    primary: true,
  },
});

Factory for CSF1-style stories ✅

It is still popular to write stories as a component when using React:

export const SomeStory = () => <Cmp><Child/></Cmp>;

We will keep supporting this pattern with factories:

export const SomeStory = meta.story(() => <Cmp><Child/></Cmp>);

Resolving the documentation burden ✅

Currently, there are 3 syntaxes that users can write configuration in (TS 4.9+, TS4.8- and pure JS):

// Button.stories.(js|ts)
import type { Meta } from '@storybook/nextjs';

// TS4.9 and above
const meta = {
  /* meta */
} satisfies Meta<typeof Button>;
export default meta;

// TS4.8 and below
const meta: Meta<typeof Button> = { /* meta */ };
export default meta;

// Pure JS
export default { /* configuration */ };

Supporting three different syntaxes (TypeScript 4.9+, TypeScript 4.8-, pure Javascript) increases documentation complexity and user confusion. With factories, we can have the same syntax for all users. And it achieves the same or better type safety, but with a single clean syntax that provides great autocompletion:

// Button.stories.(js|ts)
import preview from '#.storybook/preview';
const meta =  preview.story({ /* configuration */ });

Make a default export optional ✅

Previous we needed the meta to be exported. For CSF factories this is not necessary anymore:

// Button.stories.ts
import preview from '#.storybook/preview';
import { Button } from './Button';

const meta = preview.meta({ component: Button });

// optional
export default meta;

export const Primary = meta.story({
  args: {
    primary: true,
    label: 'Button',
  },
});

The meta runtime information is automatically merged with every story, so we don’t need it for that reason.

We also extract some data at compile time for the sidebar (like the name, title of the story).

The runtime information with factories will be automatically merged. And the compile time information, can also be extracted by looking at the meta call in the AST tree.

Stories are portable by default ✅

This also means that stories are completely portable by default. Every story will be fully prepared with all the preview and meta annotations, and you don’t need to call setProjectAnnotations in your test setup (e.g. for the vitest integration).

// SomeStory.stories.tsx

// 👇 This export is fully prepared
export const SomeStory = meta.story({
  args: { ... }
})

// some-test.test.ts
import { SomeStory } from './SomeStory.stories.tsx'

test('some test', () => {
  await SomeStory.run();
});

Here's an example of how you can reuse a story in a test file by rendering its component:

import { test, expect } from 'vitest';
import { render, screen } from '@testing-library/react';

import { Primary, Secondary } from './Button.stories';
 
test('renders primary button with default args', async () => {
  // Access the story's component via the .Component property
  render(<Primary.Component />);
  const buttonElement = screen.getByText('Text coming from args in stories file!');
  expect(buttonElement).not.toBeNull();
});
 
test('renders primary button with overridden props', async () => {
  // You can override props by passing them directly to the story's component
  render(<Primary.Component>Hello world</Primary.Component>);
  const buttonElement = screen.getByText(/Hello world/i);
  expect(buttonElement).not.toBeNull();
});

Extending a story ✅

You will be able to create a new story from an existing story:

export const Primary = meta.story({
  parameters: { some: 'parameter' },
  args: {
    primary: true,
    label: 'Button',
  },
});

export const Secondary = Primary.extend({ args: { primary: false } });

// Same as
export const Secondary = {
  ...Primary,
  args: {
    ...Primary.args,
    primary: false,
  },
}

Here, the same inheritance is used as when you go from meta to a story. Args and parameters are deep-merged, decorators are added, and render/play function is overridden.

Infer type information from argTypes/globalTypes 🚧

In some cases, the props of the component are less interesting than the child that you can put inside of it. For this, you might want to use custom args that are unrelated to the props.

Getting this correct with TypeScript in CSF3 is quite a challenge at the moment. But with factories we can support inferred patterns like below:

const meta = preview.meta({
  component: Dropdown,
  argTypes: {
    shortcuts: 'boolean',
    icon: { options: ['small', 'large', 'none'] },
    withSeperator: 'boolean',
    subGroup: 'boolean',
  },
  // 👇 We can now infer the type of `shortcuts`, `icon`, etc. from argTypes
  render: ({ shortcuts, icons, withSeperator, ...args }) => {
    return (
	    <DropdownMenu {...args}>
	      <DropdownMenuTrigger asChild>
	        <Button variant="outline">Open</Button>
	      </DropdownMenuTrigger>
	      <DropdownMenuContent className="w-56">
	        <DropdownMenuLabel>My Account</DropdownMenuLabel>
	        <DropdownMenuGroup>
	          <DropdownMenuItem>
	            { icons && <User className="mr-2 h-4 w-4" />}
	            <span>Profile</span>
	            { shortcuts && <DropdownMenuShortcut>⇧⌘P</DropdownMenuShortcut> }
	          </DropdownMenuItem>
	          <DropdownMenuItem>
	            { icons && <CreditCard className="mr-2 h-4 w-4" />}
	            <span>Billing</span>
	            { shortcuts && <DropdownMenuShortcut>⌘B</DropdownMenuShortcut>}
	          </DropdownMenuItem>
	        </DropdownMenuGroup>
	        {withSeperator && <DropdownMenuSeparator /> }
	        <DropdownMenuGroup>
	          <DropdownMenuItem>
	            <Users className="mr-2 h-4 w-4" />
	            <span>Team</span>
	          </DropdownMenuItem>
	          <DropdownMenuSub>
	            <DropdownMenuSubTrigger>
	              <UserPlus className="mr-2 h-4 w-4" />
	              <span>Invite users</span>
	            </DropdownMenuSubTrigger>
	            <DropdownMenuPortal>
	              <DropdownMenuSubContent>
	                <DropdownMenuItem>
	                  <Mail className="mr-2 h-4 w-4" />
	                  <span>Email</span>
	                </DropdownMenuItem>
	                <DropdownMenuItem>
	                  <MessageSquare className="mr-2 h-4 w-4" />
	                  <span>Message</span>
	                </DropdownMenuItem>
	                <DropdownMenuSeparator />
	                <DropdownMenuItem>
	                  <PlusCircle className="mr-2 h-4 w-4" />
	                  <span>More...</span>
	                </DropdownMenuItem>
	              </DropdownMenuSubContent>
	            </DropdownMenuPortal>
	          </DropdownMenuSub>
	        </DropdownMenuGroup>
	      </DropdownMenuContent>
	    </DropdownMenu>
  },  
});

Another case, where we can infer the type from runtime information is globals:

export default definePreview({ 
  // model globalTypes from argTypes
  globalTypes: {
    currentUser: {
      options: ['admin', 'user', 'anonymous'],
    },
  },
  async beforeEach({ globals }) {
    // 👇 We can now infer the type of currentUser directly from globalTypes    
    if (globals.currentUser) {
      await login(globals.currentUser);
    }
  },
})

Multiple preview configs 🚧

Stories for page components might need completely different defaults than story for design system components. Being able to write multiple story configs solves this:

// file: .storybook/preview.ts
import { definePreview } from '@storybook/nextjs';
import essentials from '@storybook/addon-essentials';
import chromatic from '@chromatic-com/storybook';

const preview definePreview({
  addons: [essentials(), chromatic()],
});

export default preview

// You can still export other variables as well:
export const msw = setupServer();

export const pagesPreview = preview.extend({
  decorators: [PageDecorator],
  parameters: { layout: 'fullscreen' },
  async beforeAll() {
    await msw.start()
    return msw.close;
  }),
  async beforeEach() {
    // reset the database and network to avoid hanging state between stories
    msw.resetHandlers()
    initializeDB()
  },
});

// file: note/[id]/page.stories.tsx
import { pagesPreview } from '#.storybook/preview';
import { db } from '#lib/db'
import Page from './page';

const meta = page.meta({
  component: Page,
  args: { params: { id: '1' } },
  async beforeEach() {
    await db.note.create({
      data: {
        title: 'Module mocking in Storybook?',
        body: "Yup, that's a thing now! 🎉",
        createdBy: 'storybookjs',
      },
    })
  },
})

Non-component args (Future proposal) 🚧

At some point we want to support non-component args prefixed with a $. Normally, all args of the story are automatically applied as props of the component. We would like to introduce “$-prefixed-args” (aka non-component args) as a way to get all the power of controls and args for other purposes (aside from component props).

In this way, you can use mock data in a fully declarative way and control this data in the control panel:

// .storybook/preview.ts
export default definePreview({
  // 👇 argTypes provide runtime information used to populate the controls addon
  argTypes: {
    $date: 'date' // proposed shortcut for {type: 'date'}
  },
  beforeEach: ({ args }) => {
    // 👇 We can now infer the type of $date directly from argTypes
    if (args.$date) {
      MockData.set(args.$date);
    } else {
      MockData.reset();
    }
  },
})

// Calendar.stories.tsx
import MockDate from 'mockdate';
import preview from '#.storybook/preview';

const meta = preview.meta({ component: Calendar });

// 👇 Provide mock data in a fully declerative and controllable way
const CalendarViewOnSunday = meta.story({
  args: {
    $date: new Date(...), // not applied to the component,
    events: [...] // applied to Calendar component,
  }
})

Non-component args are not a part of this proposal. Another proposal for that will come and we also consider making all parameters controllable in the controls addon, as that would fulfil the same purpose of non-component args.

[ValentinFunk]

Love this, have definitely been feeling the pain points listed here!

Make a default export optional
Does this make it possible to use the api in a way that creates multiple different metas per file? Would that be an issue / is this intended?

// AllOfMy.stories.ts
import preview from '#.storybook/preview';
import { Button } from './Button';
import { Tooltip } from './Tooltip';

const meta = preview.meta({ component: Button });
export const Primary = meta.story({
  args: {
    primary: true,
    label: 'Button',
  },
});

const tooltipMeta = preview.meta({ component: Tooltip });
export const Tooltip = tooltipMeta.story({
  args: {
    primary: true,
    label: 'Tooltip',
  },
});

This might be out of scope but one other thing regarding typing that could be improved is that parameters are not typed. Maybe there is a way to allow for type augmentation of parameters here in a way that we could get autocomplete when writing e.g.

const tooltipMeta = preview.meta({ component: Tooltip });
export const Tooltip = tooltipMeta.story({
	args: {
		primary: true,
		label: "Tooltip",
	},
	parameters: {
		docs: {
			description: {
				story: "Hover to see the tooltip.",
			},
			story: {
				height: "500px",
				inline: false,
			},
		},
	},
});

Maybe this is already possible?

[jakubriedl]

huge +1 for this feedback, parameters not being type-safe is our biggest struggle with typesafety of stories.

In our Storybook setup which is used by 20+ teams across the company we have a lot of extensions which are all controlled by parameters. From network mocks using msw, cookie mocking, date mocking through localization, user context and many more. Basically anything that has react context in the app has a decorator which allows to set it through parameters.

To enable typesafety of this we had to manually extend storybook types and put everything in there which is made even more difficult by the fact that many built in extensions don't export the parameter types and the type structure in Storybook is incredibly complicated and needs to be patched in many places. From there teams import all storybook related config from .storybook where we have a barrel file that exports all necessary and enables customization on the repo side similar to what's mentioned as #.storybook/preview import in this file.

While the proposed changes don't seem to solve these problems, it paves (a bit bumpy) path for us to streamline the monkey patching we're already doing. If we publish patched factories it'll get more standard than now, however we'd still need to create the parameters types and custom factories. It'd be great if we wouldn't have to do that.

[kasperpeulen]

We are definitely planning to make parameters typesafe and extensible!

[lishaduck]

Looks like this is/was happening: #30601!

[tobiasdiez]

I like the general direction of this proposal. The only point I'm not so sure is the proposed syntax. Coming from a vue-background, the following would feel the most natural:

import { defineMeta, defineStory } from '@storybook/...'
import { Button } from './Button';

defineMeta({ component: Button });

defineStory({
  name: 'Primary'
  args: {
    primary: true,
    label: 'Button',
  },
});

Perhaps with auto-import of the define* methods.

[kasperpeulen]

@tobiasdiez This would not give the typesafety benefits. We can not know the type of args here.

[tobiasdiez]

Is the component the only meta element that influences the type of a story? Would it be possible to move component to the story?

Alternatively, a language server supporting this kind of construction would be an option. (You call it a CSF file anyway.)

[kasperpeulen]

The component and the args, because if you set args in the meta, they become optional in the story.
In this proposal we want to make sure that even parameters used by a decorator get inferred:

const meta = config.meta({ 
  component: ProfilePage,
  decorators: [routerDecorator],
});

const MyStory = meta.story({
  parameters: {
    // 👇 this gets autocomplete, and is typesafe
    router: {
      navigation: {
        pathname: '/profile',
      },
    },
  }, 
})

That is also why config gets imported. So that if you define addons in your config, it will infer the parameters used bh addons.

Alternatively, a language server supporting this kind of construction would be an option. (You call it a CSF file anyway.)

I feel that a custom language server is not the right tradeoff for us. For example, tsc won't report the extra type safety. We need to wrap tsc in storybook-tsc to get that.

[tobiasdiez]

The component and the args, because if you set args in the meta, they become optional in the story.

Okay, fair enough. In this case you would indeed need an actual meta object that is used to construct the story. So either a construction as you proposed or perhaps

import { defineMeta, defineStory } from '@storybook/...'
import { Button } from './Button';

const meta = defineMeta({ component: Button });

defineStory({
  name: 'Primary'
  args: {
    primary: true,
    label: 'Button',
  },
  meta
});

I guess there are no real functional differences for normal usages and comes down to which syntax you like more.

In this proposal we want to make sure that even parameters used by a decorator get inferred:
That is also why config gets imported. So that if you define addons in your config, it will infer the parameters used bh addons.

In this context, I have a suggestion: have a look at how prisma and nuxt are handling this. They generate and update the typing information when you start them (i.e. here if you run any storybook command) based on the installed addons / schema etc. This has the advantage that you have the final config when generating the typing information, e.g. it is possible to have frameworks/addons/presets add their own sub-addons and having this reflected in the typing. With the right alias handling, you can then import { defineMeta } from '@storybook/react' and still have defineMeta reflect the installed addons.
Has the small disadvantage that you need to run a special command at postinstall to have the initial typing info setup for tsc and development, but otherwise its a great dev experience.
The "multiple config" extension mentioned in the above proposal however is harder to realize.

I feel that a custom language server is not the right tradeoff for us. For example, tsc won't report the extra type safety. We need to wrap tsc in storybook-tsc to get that.

Fair enough.

[matt-tingen]

I'm a big fan of this. The lack of intellisense and type-checking for things like parameters has been a pain point.

The ability to extend a config would also be a big boon to our monorepo at work where we have a consolidated storybook, but there are often decorators or parameters that should be applied to all stories in a particular package. The current requirement for meta to be statically defined means such package-level configs simply have to be repeated explicitly in all the applicable stories. Being able to extend configs would give us a mechanism for handling this in a more consolidated way.

[kasperpeulen]

Yes, we feel that as well. Better intellisense for parameters and multiple configs are two big reasons we want the new format.

[diginikkari]

I like the proposal. What I wonder is how to handle types for decorators visible for the story args? This has been one of the pain points with current model. How I have handled it currently is following:

export type DecoratorArray = readonly Decorator[];

// Utility type to extract props from decorator
export type DecoratorProps<T extends Decorator> =
  T extends Decorator<infer P> ? P : never;

/**
 * @description Convert a union type to an intersection type
 * @example
 * type A = { a: 1 };
 * type B = { b: 2 };
 * type C = { c: 3 };
 * type ABC = UnionToIntersection<A | B | C>
 * // ABC = { a: 1 } & { b: 2 } & { c: 3 }
 */
export type UnionToIntersection<Union> =
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  (Union extends any ? (argument: Union) => void : never) extends (
    argument: infer Intersection,
  ) => void
    ? Intersection
    : never;

export type UnionOfDecorators<T extends DecoratorArray> = T[number];

/**
 * Given an array of decorator functions, returns the props of the union of those decorators.
 *
 * Example:
 *   type Props = DecoratorProps<UnionOfDecorators<[(props: { a: string }) => void, (props: { b: number }) => void]>>;
 *   // type Props = { a: string } | { b: number }
 */
export type DecoratorTypes<T extends DecoratorArray> = DecoratorProps<
  UnionOfDecorators<T>
>;

/**
 * Returns the intersection of the types that the decorators in the array
 * implement.
 */
export type IntersectionOfDecoratorTypes<T extends DecoratorArray> =
  UnionToIntersection<DecoratorTypes<T>>;

/**
 * Props type for a Storybook decorator that accepts a component and additional decorator types.
 * @typeParam ComponentType - The type of the component being decorated.
 * @typeParam DecoratorTypes - An array of decorator types to be applied to the component.
 */
export type ArgProps<
  ComponentType extends // eslint-disable-next-line @typescript-eslint/no-explicit-any
    React.JSXElementConstructor<any> | keyof JSX.IntrinsicElements,
  DecoratorTypes extends DecoratorArray,
> = React.ComponentProps<ComponentType> &
  IntersectionOfDecoratorTypes<DecoratorTypes>;

These types are used like this:

const decorators = [formProviderDecorator] as const;
type Args = ArgProps<typeof AutoCompleteField, typeof decorators>;

const meta = {
  component: AutoCompleteField,
  title: 'Form Components/AutoCompleteField',
  decorators: [...decorators],
  args: {
    showDevTool: true,
  },
} satisfies Meta<Args>;

I would really love to have something build in instead.

[kasperpeulen]

Yes, we definitely have inferred decorators in mind as well!

[kasperpeulen]

This should work in the canary for decorators in defined in meta.
Will also work for decorators in preview and story in a later version.

[philwolstenholme]

This looks really promising :)

[AlmarAubel]

Looks really nice.

coming from a vue background, it would be nice if we can type the argtypes purly using typescript. Like the defineProps api in vue

export const config = defineConfig<{$date: Date}>({
   beforeEach: ({ args }) => {
    // 👇 We can now infer the type of $date directly from argTypes
    if (args.$date) {
      MockData.set(args.$date);
    } else {
      MockData.reset();
    }
  },
})

[jasikpark]

Love this! This mirrors the solution I came up with when documenting a generic Select component in a type-safe way, I decided to use a factory function:

const meta = {
  title: 'forms/<SelectAsync>',
  component: SelectAsync,
  args: {
    children: (items) =>
      items.map((itm) => (
        <SelectItem key={itm.value} value={itm.value}>
          {itm.label}
        </SelectItem>
      )),
  },
  parameters: {
    api: { disable: false },
  },
} satisfies Meta<typeof SelectAsync>;
export default meta;

type Story<T extends string, TQueryData, TQueryError extends Error, TQueryKey extends QueryKey> = StoryObj<
  typeof SelectAsync<T, TQueryData, TQueryError, TQueryKey>
>;

/** {@link makeStory} is a helper function like {@link queryOptions} to allow us to typecheck our story correctly. */
function makeStory<T extends string, TQueryData, TQueryError extends Error, TQueryKey extends QueryKey>(
  story: Story<T, TQueryData, TQueryError, TQueryKey>
) {
  return story;
}

/**
 * Loads items immediately
 */
export const Default = makeStory({
  args: {
    label: 'Option',
    getItemsQueryOptions: makeGetItemsQueryOptions(0),
  },
});

Excited to see this in the actual storybook project!

[jasikpark]

Been using this in a new project, and it's great 💖

[trappar]

The ergonomics of this seem really nice. Feels like a meaningful step toward being able to think of a story as essentially just a renderable component that can be reused from tests (though I'm sure it's far more complex under the hood).

However, my experiences trying to get it to work have all ended in dead ends. Not sure the docs are out-of-date, if I'm doing something wrong, or if the particular framework I'm using (NextJS) hasn't been updated for compatibility. I tried to make the docs' suggested changes demo projects based on both Storybook 8.6.12 and 9.0.0-beta.10, and in both cases I end up with story exports that don't seem to match my expectations based on the docs.

Expectation:
The docs here indicate that imported stories should contain both run and Component properties.

Actual:
When I try to import stories directly from my tests, each story is an object with only the following top-level keys: _tag, input, meta, and composed.

Happy to share more about my setup if that would help, but more just curious what the progress is on this reaching a fully supported release!

[kasperpeulen]

I just fixed that. See the opening post how to install the latest canary!

[Sidnioulz]

Make a default export optional

What happens if someone exports something else as a default export? It might be worth not communicating this change just so that people don't accidentally export their first story as default and end up with cryptic errors.

[kachurun]

@kasperpeulen Am I correct in understanding that all addons should be moved from main.ts to preview.ts?

[kylegach]

No, with CSF Next you still register them in main.ts (to enable their functionality) and also in preview.ts (for types).

[kachurun]

Got it, thanks for the answer

[buscape]

@kasperpeulen would it be possible to have the .Component prop for extended stories?
That would improve things for us when reusing and extending stories in test files.
I gave a bit more context in this discussion

[kasperpeulen]

Yeah, I think we could see that as a bug in the react renderer @yannbf

[Sidnioulz]

Comment coming from Discord user rb2610:

Hey all, has anyone using SB 10 with CSF Next had any luck getting args that are used only for decorators or the render function, not in the actual component to work with the new typing?

For example, we have plenty of instances of things like this:

export default {
  component: TestComponent,
  args: { containerWidth: 200 },
  decorators: [
    (story, { args }) => (
      <StoryContainer containerWidth={args.containerWidth}>
        {story()}
      </StoryContainer>
    )
  ]
} satisfies ComponentPropsWithoutRef<typeof TestComponent> & { containerWidth: number };

Where the args are used to control behaviour specific to the decorator through args that aren't props of the actual component

It seems that preview.meta can be passed generics to specify the args types, but it's not possible to pass only the args, all 3 generics have to be passed as here meta<TArgs extends Args, Decorators extends DecoratorFunction<ReactTypes & T, any>, TMetaArgs extends Partial>

So this could be achieved by doing something like this:

type Component = ComponentPropsWithoutRef<typeof EllipsisisedText> & { containerWidth: number };

preview.meta<Component, any, Partial<Component>>({

(with an actual sensible type for the decorator instead of any of course)

But this seems rather clunky, has anyone found any good solutions to this use case?

[Sidnioulz]

I've also been feeling that need personally when playing with CSF Next.

[Sidnioulz]

@mrginglymus brought up a working pattern for this, which could be prominently documented or included in the starter stories:

This is something I think I raised a while back - either story-specific args, or rewriting the types of existing args.

I think the solution proposed at the time was something like:

const StoryHarness = (props: ComponentProps & StoryProps): React.JSX.Element => {....}

const meta = preview.meta({
  Component: Component as typeof StoryHarness
});

Or something like that. It's what I use now, and it means I can avoid the faff of decorator arg injection and just do it all in the harness.

[Jazzmanpw]

Hey there! I just ran the codemod, played around a bit and found a couple of issues, but here's the one I'd like to bring to discussion. #33024 seems to be a related bug about args being the only property in the preview.meta return value, but I'd like to add more context on it here.

There are two main scenarios for a full meta:

• extending meta: a hack to group stories, e.g. component.stories.tsx, component.validations.stories.tsx, component.interactions.stories.tsx, etc.)
• reusing pieces of meta: parent component taking argTypes from a children because props are actually just passed down, and the prop itself uses control: 'select' with some string-to-jsx mapping; or borrowing beforeEach stuff from the children. Working around that with an extracted logic works if I want to reuse something within the same file. But when I want to reuse it in another stories file, I have to do all the extra settings with non-story exports, etc. Not very convenient, since I do have all the info in the meta (that I can export default, but can't use)

I tried a couple of hacks, but nothing seems to work:

• combine the old-fashioned meta with a factory call (const metaArg = {...} satisfies Meta<typeof Component>; const meta = preview.meta(metaArg); export default metaArg;, but it breaks some file parsing, it seems (maybe something related to story editing in the dev mode?)
• for the extending meta case, I tried keeping the old format for the main file and switching to factories only in [type].stories.tsx files. I had to manually preview.meta({...MainMeta, args: {...MainMeta.args, overriddenArg: 'overridden-value'}}), but TS doesn't merge types well with spreading, so it didn't work either

Probably I won't migrate to the factories for now, even though I love the type safety. Some of more complex scenarios don't work, and that perfectly fine for a preview. Thanks for the great effort towards typesafe stories! Hope to get some feedback from you regarding ideas presented here.