Support extends interface? about react-docgen-typescript-loader

[strothj]

The TypeScript library itself has the concept of a project and it's associated loaded files. There was actually a recent pull request which was merged that sped up the parsing by reusing the existing project. I'm not sure if the reason for the limitation is in this loader or the parsing project this wraps.

react-docgen-typescript has a class which is responsible for extracting types. A first step would be to see if this behavior can be reproduced in that library under Styleguidest.

As far as parsing types goes, we actually don't do any of that in this project. We take the output from that project and inject the output in a way that Storybook can use.

[donifer]

Same question here :)

[einaralex]

@strothj How would I go about extending the loader to accept an extended interface ?
I've tried a couple of different things to get this to work with the latest version, extending an interface or doing React.FC<Props & WidgetBodyProps > only returns the props of Props to the props-table.
I'm reusing props between a couple of form components and would love to be able to use this package for our component library.
Importing the reusable interface to the story doesn't seem to work either.

[SuZhou-Joe]

Please help here. Run into the same problem that extended props defined can not be detected either in story.jsx nor after compiled.

[paibamboo]

This is a bit tricky because the loader is executed once for each file seen by webpack, and at that time we have no information of some other extended interfaces imported from other files. Here's my rough idea, since loader can be asynchronous, we could wait until we iterate through every files so that we have all information before calling generateDocgenCodeBlock(). Another idea is we can gather information during loader execution, and in after compile hooks we can do something with that information.

[nextglabs]

Any workarounds for this?