FIX HMR

[ndelangen]

Issue: #11602

What I did

I don't know what changed, but this seems to fix the issue. Let's discuss!

How to test

• Open a storybook
• change a .stories.js file
• check if HMR occurs rather then page-refresh

[shilman]

Oohh cc @tmeasday

[ndelangen]

test:

• change preview.js
• expect a full reload
• change story
• expect a HMR

[ndelangen]

I verified, that changing preview.js causes a page refresh, changing the stories (or descending files causes a HMR)

[tmeasday]

Ahh, OK this makes sense.

So this change kind of reintroduces the problem that we were working around in #11431, but there is a bit more subtlety than I realised.

There are 3 scenarios of interest here (sorry @ndelangen I only thought of 2):

1. User changes an actual story file or dependent.
2. User changes a preview.js that DOES NOT call configure, such as in our OfficialSB. (This is the typical&recommended setup now).
3. User changes a preview.js that calls configure()

In case 3. as the configure() call gets passed the module it will HMR. We no longer clear decorators at all so I guess any decorators in preview.js (which there'll be less of now, I suppose) will "double up". Of course we don't let decorators run twice now anyway so this is less of a problem too, it'll probably just lead to warnings.

(Also you cannot "unset" parameters either, but that was an existing bug in 5.3 that doesn't seem to have been a big problem).

WDYT about this @shilman / @ndelangen? Should we try and be more tricky or is this OK?

[shilman]

I think we've deprecated the configure call at this point, so we can afford to optimize for the main.js stories case now.

[tmeasday]

Agreed, so I think we are OK to merge this.