Storybook: Docs addon fails to render props table when source code uses default export types

Created on 20 Jan 2020  路  19Comments  路  Source: storybookjs/storybook

Describe the bug
In a TypeScript React (non-CRA) setup with the Docs addon and the react-docgen-typescript-loader, the props table will not work if you use the React default export's properties for type definitions.

(Please ignore the fact that the example uses React.FC. It's still an issue outside of this.)

In other words...
WORKS:

import React, { ButtonHTMLAttributes, FC } from 'react';

export interface Props extends ButtonHTMLAttributes<HTMLButtonElement> {
  isDisabled?: boolean;
}

export const Button: FC<Props> = ({ isDisabled = false, ...props }: Props) => (
  <button disabled={isDisabled} {...props} />
);

DOES NOT WORK:

import React from 'react';

export interface Props extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  isDisabled?: boolean;
}

export const Button: React.FC<Props> = ({ isDisabled = false, ...props }: Props) => (
  <button disabled={isDisabled} {...props} />
);

For what it's worth, if you use a named export type for FC, but keep doing React.ButtonHTMLAttributes, then you'll only see isDisabled defined in the table.

To Reproduce
Steps to reproduce the behavior:

  1. npx -p @storybook/cli sb init --type react
  1. yarn add -D ts-loader @storybook/addon-docs @storybook/addon-info react-docgen-typescript-loader react-is babel-loader

  2. .storybook/main.js:

module.exports = {
  stories: ['../src/**/*.stories.(tsx|mdx)'],
  addons: ['@storybook/addon-actions', '@storybook/addon-links', '@storybook/addon-docs'],
  webpackFinal: async (config) => {
    config.module.rules.push({
      test: /\.(ts|tsx)$/,
      use: [
        {
          loader: require.resolve('ts-loader'),
          options: {
            transpileOnly: true,
          },
        },
        {
          loader: require.resolve('react-docgen-typescript-loader'),
        },
      ],
    });

    config.resolve.extensions.push('.ts', '.tsx');

    return config;
  },
};

and create some stories to compare!

Expected behavior
I should be able to create stories regardless of how I use types from dependencies.

System:

Environment Info:

  System:
    OS: macOS Mojave 10.14.6
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 10.18.1 - ~/.nvm/versions/node/v10.18.1/bin/node
    Yarn: 1.21.1 - ~/.nvm/versions/node/v10.18.1/bin/yarn
    npm: 6.13.4 - ~/.nvm/versions/node/v10.18.1/bin/npm
  Browsers:
    Chrome: 79.0.3945.130
    Safari: 13.0.4
  npmPackages:
    @storybook/addon-actions: ^5.3.6 => 5.3.6 
    @storybook/addon-docs: ^5.3.7 => 5.3.7 
    @storybook/addon-info: ^5.3.7 => 5.3.7 
    @storybook/addon-links: ^5.3.6 => 5.3.6 
    @storybook/addons: ^5.3.6 => 5.3.6 
    @storybook/react: ^5.3.6 => 5.3.6 
docs argstable bug todo typescript

Most helpful comment

Go away

All 19 comments

My understanding is that this has been an issue for a while and is due to the limitations of react-docgen-typescript-loader, due to its reliance on react-docgen-typescript.

The limitations are called out at https://www.npmjs.com/package/react-docgen-typescript-loader#limitations and https://github.com/styleguidist/react-docgen-typescript#example.

I would love for this to be addressed too if possible.

@jeffu92 are you familiar with react-docgen's typescript support? we're hoping to move to that in 6.0 to simplify things and hopefully address some of these issues.

@shilman Not particularly, unfortunately. I just ran into this issue myself recently, so figured I'd share what I found.

@jeffu92 FWIW the link you shared is discussing the need for your source code to use named exports. I don鈥檛 think they realize the limitation of using default exports from dependencies as external types.

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

still a bug

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

Go away

@kylemh can you try the recommended 6.0 setup (should work in 5.3 too) and based on the repro linked above I expect the problem to be fixed:

https://github.com/storybookjs/storybook/blob/next/MIGRATION.md#react-prop-tables-with-typescript

I'll give it a whirl tomorrow!

I gave this a try in other projects, but wasn't successful - although I'm a bit sleep-deprived.

Theoretically, I should be able to take this minimal TSDX + React + Storybook repo, and do:

1) yarn remove react-docgen-typescript-loader
2) yarn add @storybook/preset-typescript (to get latest version of preset)
3) Move preset declaration from .storybook/main.ts's addons field (as opposed to presets field).

And be good to go, right?

Seems to still be an issue, but it sounds like there's a PR for the fix here:
https://github.com/reactjs/react-docgen/pull/352

Please ignore the fact that the example uses React.FC. It's still an issue outside of this.

Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!

reactjs/react-docgen#352 is still open 馃し

Yeah @kylemh I still don't have a good strategy to deal with this. Fixing bugs in react-docgen or react-docgen-typescript is probably outside the scope of what we can handle in Storybook. In the short term I'm afraid we'll have to support both to some degree. Although it is a code / documentation / support nightmare.

Since the solution is outside the scope of the project, please feel free to close the issue!

Any progress in this issue? @shilman

Reopening this. Although this is a limitation of another library, we should track it and figure out a fix one way or another.

Was this page helpful?
0 / 5 - 0 ratings