HMR Issues

[arunoda]

I've found some weird HMR issues. It's pretty hard to reproduce but possible.

Simply run our shared-modules example with the latest master.
Then try to changes components/Header.js pretty quickly.
The ideas is to do a change before Webpack builds the prev change.

After that point, we won't get any HMR updates. Only remedy is to reload the page.

I'm not whether this is our bug, webpack's bug

Disable HMR

When I trying to do a hot-fix, I simply remove HMR and do a client reload for every change instead. Actually, it was fast as HMR changes and I didn't feel any difference.
And it reduce some of our code liabilities related to HMR.

So, I'm proposing to remove HMR at all.
@rauchg @nkzawa what do you guys think?

[eezing]

Although the performance diff may be negligible, HMR is indispensable when working on stateful components and/or redux.

I have two apps in production built with Next and I can honestly say overall stability and performance of HMR is rather good. You guys have done a fine job with this so far.

I personally would not address HMR until non-contributors raise issues.

[arunoda]

Although the performance diff may be negligible, HMR is indispensable when working on stateful components and/or redux.

That's a good point.

I personally would not address HMR until non-contributors raise issues.

Actually, this came when testing our app zeit.co.

[arunoda]

But if there's a way to fix this, I'd love to have it.

[timneutkens]

Related to #1083?

[arunoda]

@timneutkens nope. Actually, webpack builds it correctly. But the client doesn't get updates.

[eezing]

I can't for the life of me break break HMR. I've tried in my own projects as well as examples/shared-modules. Works every time. Ideas???

[eezing]

@arunoda can you reproduce in incognito (more specifically clear application data & cache)

[rauchg]

I absolutely love HMR and it's indispensable. We should fix it, not remove it.

[mojo5000]

Sry guys - curious if there was any movement on this. I love HMR, but is there an option to turn it off? It is killing my redux state, a separate issue that may be resolved by another fix, but I'd like the option.

[arunoda]

No. We are not going to do this.

[eezing]

@mojo5000 Your problem should be fixable by declaring your store outside of your react component tree. Then during development, only create the store one time. Something like so:

var store;

const myComp = () => {
  
    if (!store || process.env.NODE_ENV === 'production') {
      store = createStore();
    }
    
    return <CoolComp store={store} />;
}

export default myComp;

[arunoda]

Thanks @eezing for helping out @mojo5000

[mojo5000]

Thanks, already doing something similar in an HOC. I think the problem is actually related to a redux-form issue with doing a destroy on unmount + accounting for hotloading that got reverted.

redux-form/redux-form#623

Trying to verify.

(Don't want to put unrelated proj info in here but I think this is the most used Redux form library for the React community, and there is some overall trickiness with next and Redux that relates to it.)

[Zn4rK]

@mojo5000, did you find a solution for this? I'm running into the exact same problem.