Disable HMR for web-components projects #372
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #370.
When using
storyStoreV7
, we configure HMR to swap out theimportFn
when stories change. However, this breaks web-components projects (see https://github.com/storybookjs/storybook/tree/master/app/web-components#setup-page-reload-via-hmr).So, instead, this change checks if the framework is
web-components
and if so, refreshes the page instead of performing an HMR. It's still pretty quick, and not a full page reload.You can test this out by starting up our
lit-ts
example (which I've configured to use storyStoreV7 now), open the story, and save the component or story file. It shouldn't blow up anymore.One bummer is that MDX files also no longer HMR, though technically they could. But I can't find a way to detect which part of the
importFn
changed, in order to determine whether to HMR or not, and it's safer to just avoid it for all stories when using web-components.