Why CSF Args Type is Partial type ?

[ka2jun8]

Describe the bug

I use storybook for react on TypeScript and create stories using CSF format.

like this:

Component

type Props = {
  title: string;
  descriptions: string[];
};

export default function App(props: Props) {
...

Story

const meta: Meta = {
  title: "App",
  component: App
};
export default meta;

const Template: Story<React.ComponentProps<typeof App>> = (args) => (
  <App {...args} />
);

export const NgPattern = Template.bind({});

// expect type error
NgPattern.args = {
  title: "Title"
  // descriptions: [],
};

I do not know why component arg type is not strict.
If I make a mistake in using it, please let me know.

To Reproduce

https://codesandbox.io/s/sharp-raman-2rbk6?file=/src/App.stories.tsx

Expected behavior

The props types error is showed like this:

Property 'descriptions' is missing in type '{ title: string; }' but required in type 'Props'.

System

Environment Info:

  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-8569U CPU @ 2.80GHz
  Binaries:
    Node: 14.15.4 - ~/.nodebrew/current/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.11 - ~/.nodebrew/current/bin/npm
  Browsers:
    Chrome: 88.0.4324.96
    Edge: 87.0.664.57
    Firefox: 70.0.1
    Safari: 14.0
  npmPackages:
    @storybook/react: 6.1.15 => 6.1.15

Additional context

If here type args?: Partial<Args>; become args?: Args;, It works as expected.

https://github.com/storybookjs/storybook/blob/next/lib/addons/src/types.ts#L171

[Vincent-Alibert]

I have the same problem with args?: Partial<Args> for use Args composition... I can't because Partial turn the keys object to potentially undefined... i need use keyword as or set in TSConfig ** strictBindCallApply: false,**

export type TIdentify = { className: string; id: string };

export interface IButtonProps {
  color: string;
  label: string;
  identity: TIdentify;
}
// Button.stories.tsx
import { Story, Meta } from "@storybook/react/types-6-0";
import Button, { IButtonProps, TIdentify } from "./Button";

export default {
  title: "Test",
  component: Button,
} as Meta;

const Template: Story<IButtonProps> = (args) => <Button {...args} />;

export const Primary = Template.bind({});

Primary.args = {
  color: "blue",
  label: "Primary",
  identity: {
    className: "first",
    id: "first",
  },
};

export const PrimaryLongName = Template.bind({});

PrimaryLongName.args = {
  identity: {
    ...(Primary.args.identity as TIdentify),
    id: "second",
  },
};
#

[VictorLandim]

I would also love to see this addressed. It seems that casting the arg to component prop type is the only solution for now, although verbose.

[ghost]

Also bumping into this issue when trying to use args in jest tests

[olivierpascal]

I would also love to see this addressed. It seems that casting the arg to component prop type is the only solution for now, although verbose.

This is what I do, and yes, this is unnecessarily verbose, check basic example below.

import React from 'react';
import { Story, Meta } from '@storybook/react';

import Component, { ComponentProps } from './Component';

export default {
  title: 'atoms/Component',
  component: Component,
} as Meta;

// Using an intermediate type is not required but sometimes useful.
type TemplateProps = Omit<ComponentProps, 'children'>;

const Template: Story<TemplateProps> = (props) => (
  <Component {...props}>Hello World</Component>
);

export const Default = Template.bind({});
// Using an intermediate variable to strictly type args.
const defaultArgs: TemplateProps = {
  propA: true,
  propB: 'x',
};
Default.args = defaultArgs;

[shilman]

Apologies for the lack of response here. This has been discussed extensively on another issue (or maybe a PR) but after 10 minutes of searching I wasn't able to find it. (cc @yannbf @tmeasday who both weighed in before).

The reason that Args/ArgTypes are Partials by default is because of the way Storybook composes things hierarchically.

Consider the following component:

// MyComponent.tsx;
export interface MyProps {
  a: string;
  b: string;
}

export const MyComponent = (props: MyProps) => JSON.stringify(props);

And stories:

// MyComponent.stories.tsx
import { Meta, Story } from '@storybook/react';
import { MyProps, MyComponent } from './MyComponent';

export default {
  args: { a: 'hello' };
} as Meta<MyProps>

export const MyStory: Story<MyProps> = (args) => <MyComponent {...args} />;
MyStory.args = {
  b: 'goodbye';
};

Since Storybook composes args hierarchically, the story function's argument is a fully specified args object even though default.args and MyStory.args are both only partially specified. Unfortunately there's no easy way to specify that in Typescript AFAIK. And unfortunately this hierarchical composition is the recommended way to write stories in Storybook.

I appreciate that the current type system is deficient, so I'd love to come up with a resolution for this. There were a few proposals to address this last time around:

1. Change the types to be strict, and users can write Meta<Partial<MyProps>> by hand if they want that behavior. Or we could add PartialMeta/PartialStory if we wanted to save a few characters. This isn't great because it complexifies the recommended usage of Storybook.
2. Introduce new types that are strict, e.g. StrictMeta/StrictStory which allows for this strict use case for users who want it. I think I prefer this approach.

Alternatively perhaps there is some Typescript magic that can help the situation? Or we need to rethink Storybook's composition, which I don't see happening but am open to proposals on.

What do you think?

[KevinMind]

@shilman I think you could make the argument that compositional nature of args has nothing to do with their type integrity.

compose(obj1, obj2, obj3) should not assume that all instances of obj are partial types, otherwise how do you know that at least 1 specifies all valid props? Do you do some kind of inference unioning magic?

It seems to me that 1 is the better option as it is much easier to create a partial when you want, than to have to work totally around the storybook types to get them stricter.

[ka2jun8]

@shilman

I understood. Thanks.

Please give me a link if you have the appropriate documentation.
I couldn't read the intent in the following documents...

https://storybook.js.org/docs/react/api/csf

[donaldpipowitch]

PartialStory ... or ... StrictStory

One or the other would already work for me 😊 No preference which one from my side.

is the recommended way to write stories in Storybook

I wasn't really aware of that. I'd say I'm a vivid Storybook user, but still it's hard for me to keep track of things like that.

Official Storybook ESLint rules or a Storybook language server might help here in the future. Depending on whether you use export default { args } it could recommend to either use Story or StoryStrict for example. (An ESLint rule could auto-fix this. A language server could offer suggested quickfixes.)

[kasperpeulen]

I have playing around with the following helper which makes sure that the relationship between meta and stories is understood by typescript:

const createMeta = <P, D extends Partial<P>>(meta: { component: ComponentType<P>; args: D } & Meta<P>) =>
  [meta, (story: { args: Omit<P, keyof D> } & Story<P>) => story] as const;

So say we have this component:

export const MyComponent = (props: { a: string; b: string }) => <>{JSON.stringify(props)}</>;

We can create meta and a story creator using createMeta:

// Infers P (props) from MyComponent, and D (default props) from args
const [meta, createStory] = createMeta({ component: MyComponent, args: { a: "hello" } }); 
export default meta;

If we wrap our story exports with createStory everything gets inferred now:

export const MyStory = createStory({ args: { b: "goodbye" } }); // Fine as "a" has a default value
export const MyStory2 = createStory({ args: { a: "hello hello" } }); // Error: Property 'b' is missing in type '{ a: string; }'
export const MyStory3 = createStory({ args: { a: "hello hello", b: "goodbye" } }); // Fine you can overwrite defaults

This is using the new CSF 3 format, using features: { previewCsfV3: true } and I tested it with 6.4.0-alpha.30.

Note that, this is not doing any imperative magic. It is just exporting plain javascript objects, but the createStory makes sure it understand which args are required and which not.

It will export the same javascript object as the following:

export default { component: MyComponent, args: { a: "hello" } } as ComponentMeta<typeof MyComponent>;
export const MyStory: ComponentStory<typeof MyComponent> = { args: { b: "goodbye" } }; 
export const MyStory2: ComponentStory<typeof MyComponent> = { args: { a: "hello hello" } }; 
export const MyStory3: ComponentStory<typeof MyComponent> = { args: { a: "hello hello", b: "hello hello" } };

A lot more type annotations, but impossible for typescript to find the error in this way.

[KevinMind]

I've tried this also, but I get NoMetaError in runtime as it seems storybook is not allowing you to export the return value of a function in stories in v7.

[kasperpeulen]

Discussed another approach with @shilman and @yannbf that doesn't use factories so that we have predictable AST for tools to statically analyze:

The helper:

import type { Meta, Story } from "@storybook/react";
import type { ComponentType } from "react";

export type CSFType<M extends Meta> = M extends {
  component: ComponentType<infer P>;
  args: infer D;
}
  ? { args: Omit<P, keyof D> } & Story<P>
  : never;

The component:

export const MyComponent = (props: { a: string; b: string }) => <>{JSON.stringify(props)}</>;

The story:

import type { CSFType } from "./helper";
import { MyComponent } from "./my-component";

const meta = { component: MyComponent, args: { a: "a" } };
type Story = CSFType<typeof meta>;

export default meta;
export const MyStory1: Story = { args: { b: "goodbye" } }; // Fine, a has default
export const MyStory2: Story = { args: { a: "hello hello" } }; // Error: Property 'b' is missing in type '{ a: string; }'
export const MyStory3: Story = { args: { a: "hello hello", b: "goodbye" } }; // Fine, can overwrite a

[shilman]

Love this approach @kasperpeulen ❤️

Let's make it happen! Is this a breaking change or can it be added alongside the current types?

I think this would be a fantastic addition to CSF3 🎁

[steven-prybylynskyi]

I've just upgraded to 6.4 beta and using ComponentStoryObj<typeof CbSelect> as in this example https://github.com/storybookjs/storybook/blob/next/examples/react-ts/src/AccountForm.stories.tsx#L21 to aid in autocompletion.

We use Chakra UI components and unfortunately there's none for the args parameter when the component is wrapped with Chakra Factory:

/* Component.tsx */

import { FC } from 'react';
import { chakra, SelectProps } from '@chakra-ui/react';

export interface CbSelectProps extends SelectProps {
  options: SelectOption[];
  label?: string;
}

const CbSelectBase: FC<CbSelectProps> = ({ options, label, id, ...props }) => ( ... )

export const CbSelect = chakra(CbSelectBase);

/* Component.stories.tsx */

export const SelectDefault: ComponentStoryObj<typeof CbSelect> = {
  args: {
    // no autocompletion here
  },

It was working in a former alpha version

[tmeasday]

@pribilinskiy what does typeof CbSelect end up as in this case?

[steven-prybylynskyi]

Thx @tmeasday for chiming in
Here's the signature of the factory function
It returns ChakraComponent<T, P>

As I see it combines ChakraProps & component's Props

[tmeasday]

@pribilinskiy could you put a reproduction of the issue together? Which alpha was it working in?

[steven-prybylynskyi]

Not sure, solved by using the StoryObj<CbButtonProps> interface instead

[IanVS]

It looks like satisfies has been merged, but not yet released. 🤞 that it is released soon. microsoft/TypeScript#46827

[bmingles]

I ended up writing a util function to help with this:

/** Remove the Partial<> constraint from TArgs */
export type StoryRequiredArgs<TArgs> = Story<TArgs> & { args: TArgs };

export function templateBindRequireAllArgs<TArgs>(
  template: Story<TArgs>,
): StoryRequiredArgs<TArgs> {
  return template.bind({}) as StoryRequiredArgs<TArgs>;
}

...

const Template: Story<SomeProps> = (args) => <Some {...args}/>

// Use the util instead of Template.bind({})
export const MyStory = templateBindRequireAllArgs(Template)
MyStory.args = { ... } // all props should be required here now

[shilman]

Yippee!! I just released https://github.com/storybookjs/storybook/releases/tag/v7.0.0-alpha.37 containing PR #19238 that references this issue. Upgrade today to the @next NPM tag to try it out!

npx sb upgrade --prerelease

Closing this issue. Please re-open if you think there's still more to do.

[cesarriva]

Not sure if it's still relevant, I suffered the same problem and solved this way:

<WarningAlertStory
   {...(WarningAlertStory.args as Required<BrAlertProps>)}
/>

[kasperpeulen]

@cesarriva In storybook 7 alpha you can write for a component like this:

export const MyComponent = (props: { a: string; b: string }) => <>{JSON.stringify(props)}</>;

import type { Meta, StoryObj } from '@storybook/react';

const meta = {
  component: MyComponent,
  args: { a: 'a' },
} satisfies Meta<typeof MyComponent>;

export default meta;
type Story = StoryObj<typeof meta>;

export const MyStory1: Story = { args: { b: 'b' } }; // Fine, a has default
export const MyStory2: Story = { args: { a: 'a' } }; // Error: Property 'b' is missing in type '{ a: string; }'
export const MyStory3: Story = { args: { a: 'a', b: 'b' } }; // Fine, can overwrite a

[aaronadamsCA]

Is there any chance these new types could be backported to @storybook/types v6.x, to help with v7 migration prep? Especially now that TS 4.9 and the satisfies operator have arrived.

[andykenward]

@cesarriva In storybook 7 alpha you can write for a component like this:

export const MyComponent = (props: { a: string; b: string }) => <>{JSON.stringify(props)}</>;

import type { Meta, StoryObj } from '@storybook/react';

const meta = {
  component: MyComponent,
  args: { a: 'a' },
} satisfies Meta<typeof MyComponent>;

export default meta;
type Story = StoryObj<typeof meta>;

export const MyStory1: Story = { args: { b: 'b' } }; // Fine, a has default
export const MyStory2: Story = { args: { a: 'a' } }; // Error: Property 'b' is missing in type '{ a: string; }'
export const MyStory3: Story = { args: { a: 'a', b: 'b' } }; // Fine, can overwrite a

@aaronadamsCA
You can also do this in Storybook 6.5. The type imports are named differently.

So this @storybook/react v7

import type { Meta, StoryObj } from '@storybook/react';

changes to this for @storybook/react v6.5

import type { ComponentMeta, ComponentStoryObj } from '@storybook/react';

Full example

import type { ComponentMeta, ComponentStoryObj } from '@storybook/react';

const meta = {
  component: MyComponent,
  args: { a: 'a' },
} satisfies ComponentMeta<typeof MyComponent>;

export default meta;
type Story = ComponentStoryObj<typeof meta>;

export const MyStory1: Story = { args: { b: 'b' } }; // Fine, a has default
export const MyStory2: Story = { args: { a: 'a' } }; // Error: Property 'b' is missing in type '{ a: string; }'
export const MyStory3: Story = { args: { a: 'a', b: 'b' } }; // Fine, can overwrite a

This does not work. See #13747 (comment)

[aaronadamsCA]

@andykenward This doesn't work with the latest @storybook/react v6.5.13, you can't do type Story = ComponentStoryObj<typeof meta>. The TypeScript error is Type '{ component: any; args: { a: string; }; }' does not satisfy the constraint 'keyof IntrinsicElements | JSXElementConstructor<any>'.

This appears to be because the (awesome!) new types from #19238 haven't been backported to types-7-0.ts on the v6.5.x release line.

[gynekolog]

@kasperpeulen The meta annotated with the satisfies is skipped during the dev build.
reproduction: https://codesandbox.io/s/storybook7-vite-xsem9z?file=/src/Button/ButtonLegacy.stories.tsx
message: Skipping src/Button/Button.stories.tsx: Or: CSF: missing default export /sandbox/ src/Button/Button.stories.tsx (line 1, col 0)

[kasperpeulen]

@gynekolog We noticed that issue indeed as well. We are working on a fix!

#20033

@aaronadamsCA You are right. We could backport it indeed, leaving that decision for @shilman.

Note that the 7.0 types are backward compatible with 6.x, so you can migrate them to satisfies after migrating to 7

This is also valid in 7 (though you will get deprecations warnings in your editor):

export default {
  component: MyComponent,
  args: { a: 'a' },
} as ComponentMeta<typeof MyComponent>; // or Meta<typeof MyComponent>;

type Story = ComponentStoryObj<typeof MyComponent>; // or StoryObj<typeof MyComponent>

export const MyStory1: Story = { args: { b: 'b' } }; // Fine, a has default
export const MyStory2: Story = { args: { a: 'a' } }; // Doesn't error with the 6.x syntax
export const MyStory3: Story = { args: { a: 'a', b: 'b' } }; // Fine, can overwrite a

[shilman]

@aaronadamsCA unfortunately we don't patch things back unless it's a severe bug AND a non-disruptive change. I feel like this is neither. Fortunately, 7.0 is going to beta soon and hopefully will be stable enough to upgrade to before too long!

[aaronadamsCA]

@shilman Makes sense! Just note this means Storybook latest ships "v7 types" that aren't. I do think that's fine, though, since the new types are significantly more complex.

Can't wait to try v7! We'll make the jump as soon as Babel configs are fixed up.

[shilman]

Oh sorry I didn't read that far back in the thread (was on my phone) so I totally misunderstood the ask. We could potentially do something here. Will discuss with @kasperpeulen offline

[aaronadamsCA]

Got it. If you do decide to backport #19238, make sure to include #20088 as well, please! Thanks.

[gburning]

Sorry for bumping an older thread, but was this issue reintroduced in Storybook 7 (specifically @storybook/vue3)? From what I can see, StoryObj['args'] is defined as optional even when the component requires them.

[kasperpeulen]

@gburning Next to that, it works with vue-tsc and with VSCode in combination with the volar plugin.

[gburning]

Sure! I have a component with:

    export interface Props {
        buttonProps: {
            label: string
            theme: string
        }
    }

    const props = defineProps<Props>()

Then my stories file for that component looks like:

const meta: Meta<typeof BaseMenuButton> = {
    component: BaseMenuButton
}
export default meta

type BaseMenuButtonStory = StoryObj<Props>

export const WithRequiredProps: BaseMenuButtonStory = {
    render: (args) => h(BaseMenuButton, args),
    args: {
        buttonProps: {
            label: 'Button label',
            theme: 'primary',
        }
    },
}

export const Secondary: BaseMenuButtonStory = {
    ...WithRequiredProps,
    args: {
        buttonProps: {
            ...WithRequiredProps.args.buttonProps,
            theme: 'secondary',
        },
    },
}

With that setup I get 'WithRequiredProps.args' is possibly 'undefined'.ts(18048) when trying to reuse WithRequiredProps.args.buttonProps.

[IanVS]

To get more complete type safety, you can use TypeScript 4.9+ and the satisfies keyword as explained in this blog post: https://storybook.js.org/blog/improved-type-safety-in-storybook-7/

[kasperpeulen]

Right, you also don't need a render function anymore!

[gburning]

Hmm ok, I'll have a look and see if I can upgrade to TS 4.9 :)