Next.js: Remove `react-hot-loader`

Created on 29 May 2018 · 9Comments · Source: vercel/next.js

It causes way more issues than it fixes.

It's a matter of removing it from babel options

    plugins: [dev && !isServer && hotLoaderItem, dev && reactJsxSourceItem].filter(Boolean)

becomes

    plugins: [dev && reactJsxSourceItem].filter(Boolean)

Source

rauchg

👍6 🎉1

Most helpful comment

I confirm, it works like a charm with @material-ui/styles. I have also the feeling that the end-to-end time for hot reloading has greatly improved 🚀 .

oliviertassinari on 19 Jun 2018

🎉2

All 9 comments

It’s a little more involved than just removing the babel plugin. Also requires to rewrite the provider component they have to handle errors with componentDidCatch. I’m planning to fix this after a bug fix when using _app.js

timneutkens on 29 May 2018

👍2

I wonder, which exactly issues does it cause?

ArmorDarks on 30 May 2018

@ArmorDarks Some changes made in RHL 4.1.0 cause this problem: https://github.com/zeit/next.js/issues/4232

Everettss on 30 May 2018

What's alternatives? How we should auto-refresh page on changes?

ex3ndr on 16 Jun 2018

Note that react-hot-loader !== hot reloading. Hot reloading still works. The only thing react-hot-loader did was keeping state, but there were too many cases in which it caused weird and unexpected behaviour. For example shouldComponentUpdate being overriden etc.

timneutkens on 16 Jun 2018

I confirm, it works like a charm with @material-ui/styles. I have also the feeling that the end-to-end time for hot reloading has greatly improved 🚀 .

oliviertassinari on 19 Jun 2018

🎉2

Good to hear @oliviertassinari 😌

timneutkens on 19 Jun 2018

This seems to have decreased hot reloading from a worst case of minutes to seconds for a handful of views, now it seems to perform as good as next.js v4, or even better. And some strange edge cases in development have disappeared. Great work.