[Change request] Disable reactDocgen task in storybook build, increasing SB build performance
See original GitHub issueThis makes storybook rebuild components considerably faster:
// `web/config/storybook.config.js`
module.exports = {
addons: [ /* ... */ ],
features: { /* ... */ },
/** @see {@link https://storybook.js.org/docs/react/configure/typescript} */
typescript: {
reactDocgen: false,
}
}
Although the “docs” tab is not used in the RedwoodJS storybook setup at all, it seems to be included in the storybook dependency stack and executed by default. This causes re-rendering to pause / stop / meditate / waste our precious time at 70% of the rebuilt:
Above snippet disables this build step. An additional comment could be added so RedwoodJS users know where to look should they ever decide they need the DogGenPlugin in their storybook.
Would have contributed this as PR straightaway, but somehow could not find the origin of web/config/storybook.config.js
in this repo.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:10 (7 by maintainers)
Top Results From Across the Web
MIGRATION.md - Storybook - Fossies
SB 6.4 introduced experimental "auto-title", in which a story's location in the sidebar (aka title ) can be automatically inferred from its location...
Read more >@storybook/addon-controls | Yarn - Package Manager
Storybook Controls gives you a graphical UI to interact with a component's arguments dynamically, without needing to code. It creates an addon panel...
Read more >Storybook in create-react-app with TypeScript - Stack Overflow
I get storybook to build but it shows: No Preview Sorry, but you either have no stories or none are selected somehow. This...
Read more >https://raw.githubusercontent.com/storybooks/story...
... Bug Fixes - Core: Fix symlinks in static dir when building static Storybook ... Addon-controls: Improve color picker UI and migrate to...
Read more >storybookjs/storybook (Raised $170.00) - Issuehunt
storybookjs/. storybook. The UI component explorer. Develop, document, & test for React, Vue, Angular, Ember, Web Components, & more! Owners: Follow ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
My guess is that this is a miss on our part. @virtuoushub a good next step with the Storybook team would be to set up an audit where they critique our default setup and let us know what might be missing and what might be uneccesary. Also, this work was originally done by Peter P. — we can loop him in when the time is right.
Near-term
As of 1.0, removing anything is technically a breaking change unless we can demonstrate otherwise. I think our next steps to get there should be:
How does all that sound?
Hey @virtuoushub thanks for your patience with me until here – there actually was a lack of understanding from my side for quite a while. I have tested with re-enabled
reactDocgen: 'react-docgen' | 'react-docgen-typescript'
and now finally understand what you mean when you say… i sincerely didn’t get it, although now as i see it, it kinda obvious 🤦 😆
When we set
react-docgen: false
in our project back then, we were simply happy with the enormous performance gain and only now i realize why i haven’t missed any “auto-generated” controls for a second: b/c they simply never worked for us – much to the contrary, they were a real nuisance.Our project is all Chakra UI, and that means our custom components either get a listing of ~63 inferred controls of which we normally want to touch three in average, with basically all the others requiring an object configuration making the whole component break as soon as the <kbd>Set object</kbd>-Button is clicked – or we’ll not get a single one (for any component using
forwardRef
that is).BTW, i can confirm that
react-docgen
(as opposed toundefined
orreact-docgen-typescript
) is really fast, but in my tests it did not render a single control, so again it’s pointless to our project.Now as i have retested it i can only affirm that i’d never go back to the default setting – configuring a few controls via the
args
-argument with exactly the options i want is very simple and actually preferable for me, while i get usability and performance gains on top for free 😃But absolutely hear you when you say that people with other project setups have very good experiences with it and that you want to keep an “all batteries included”-philosophy for freshly created RedwoodJS projects.
Hence my suggestion would be to keep the default setting, but give developers a hint about their options in the config-file, something like:
What do you think?