storybook: Docs addon fails to render props table when source code uses default export types
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:
-
npx -p @storybook/cli sb init --type react -
yarn add -D ts-loader @storybook/addon-docs @storybook/addon-info react-docgen-typescript-loader react-is babel-loader -
.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
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 20 (14 by maintainers)
Commits related to this issue
- Props: #9556 repro — committed to storybookjs/storybook by shilman 4 years ago
Go away
Yeah @kylemh I still don’t have a good strategy to deal with this. Fixing bugs in
react-docgenorreact-docgen-typescriptis 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.Reopening this. Although this is a limitation of another library, we should track it and figure out a fix one way or another.
Since the solution is outside the scope of the project, please feel free to close the issue!
I’ll give it a whirl tomorrow!
@shilman Not particularly, unfortunately. I just ran into this issue myself recently, so figured I’d share what I found.