Open schoonc opened 4 years ago
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!
On my end, the Canvas is taking about 5 seconds to re-render after a prop is changed in ArgsTable on DocsPage.
^ should specify that's if there are like 12 stories on the page, which I have. With just one story, the re-render is instantaneous even in dev mode.
@as-zlynn-philipps this should help a lot https://github.com/storybookjs/storybook/pull/14002
can you please upgrade to the beta and let me know what you see?
npx sb upgrade --prerelease
@shilman thanks! Tested and counted this time. Seems like it's taking 1-11 seconds to re-render in dev mode with several stories on each prop change. I can't discern any rhyme or reason for the different lag times.
I'm experiencing the original issue. Nothing to do with lag, it just makes storybook unhelpful for certain kinds of components.
For example, a component that uses css transitions to animate state changes can't be tested in storybook because it's redrawn when props are changed. The redraw first resets everything to default values, then applies the new prop value, so there's a jump where there should be a transition.
hi, any updates?
Still seeing this in 6.5.10
Describe the bug The entire component is redrawn when properties are changed in the "Docs" section.
To Reproduce Steps to reproduce the behavior:
git clone https://github.com/schoonc/test-storybook-vue-docs-render
npm i
npm run storybook
Expected behavior The component must not be completely redrawn.
Screenshots
Code snippets dependencies in the package.json:
.storybook/main.js:
stories/testdiv.css:
stories/Testdiv.stories.js:
stories/Testdiv.vue:
System
It would be interesting to know the reason for such behavior. And if it is technically justified (e.g. technically difficult to implement at the moment), it would be cool to describe this behavior in documentation.