Next.js: Disable Fast Refresh

[slava-lu]

How can I revert back to the old (9.3 ) HMR in 9.4? Is there any config parameter?
It looks like fast refresh does not work very well with third party design systems like e.g. baseweb

[Timer]

Please provide reproducible code and we can figure out why Fast Refresh isn't working as intended.

[montezume]

I would also like to disable fast refresh, as I can't allow eval (even during development), so it breaks my CSP policy and I can't update :(

[montezume]

Sorry, I realized that my problem is not with fast-refresh, but with the webpack devtool. I changed to a non-eval based devtool and it worked with our CSP

[idlefingers]

Some libraries have bugs which cause things to not work well with fast refresh. Here's a reproducible example of xstate's useMachine hook not updating when the page is refreshed: https://github.com/idlefingers/next-xstate-fast-refresh-bug

And issue on xstate's repo: https://github.com/davidkpiano/xstate/issues/995

[njbarrett]

I would also like to see the option available to not use fast refresh, its a blocker for me using 9.4

[Timer]

@idlefingers I'd argue it's a good thing that Fast Refresh is exposing bugs in libraries, and is not grounds to disable it in Next.js.
Please work with the library author to fix their package!

---

@njbarrett could you explain why? You didn't provide any reproduction or reason.

[idlefingers]

@Timer yeah, for sure. Makes it a pain to develop with in the meantime though.

[mrassili]

ditto, this should be configurable

[Timer]

Closing as no reproduction has been provided. Happy to fix any bugs users find and can provide a demo for.

[steveruizok]

@idlefingers I'd argue it's a good thing that Fast Refresh is exposing bugs in libraries, and is not grounds to disable it in Next.js.
Please work with the library author to fix their package!

Do you have a guide for package authors on how to ensure that state works correctly with next's implementation of Fast Refresh? Would any advice from React Native's implementation also work in Next, or are there nuances that authors should know about?

[Timer]

The impl and nuances are identical to that of React Native.

[nfantone]

@Timer Today, I stumbled upon another example of library incompatibility with the new Fast Refresh implementation. use-debounce stops working altogether after any changes to code are made.

You can see a reproduction example here: https://codesandbox.io/s/hardcore-sara-ueu2k

Looks fine on first load, but doesn't call the input callback anymore after refresh.

After initial load

After [Fast Refresh] done

[xnimorz]

Hi @nfantone , @Timer
The main tricky thing, why lots of third party libraries get crashed during fast-refresh updates, is fast-refresh re-calls (with cleanups) all useEffects inside custom hooks, components, etc.

I mean, the following code wouldn't work properly:

function MyComponent() {
  const isComponentUnmounted = useRef(false);
  useEffect(() => () => {isComponentUnmounted.current = true}, []); 
}

In the example above, we change ref to the truth inside useEffect cleanup function (which is handy to prevent unnecessary timers, callbacks, etc).
Usually, this code works correctly. But fast-refresh re-runs all useEffects, which leads to all cleanups call, and then useEffect would be called again.

I've fixed it, by publishing a new version: [email protected].

Here is an example of such fixes, I hope it could be helpful: https://github.com/xnimorz/use-debounce/commit/2ac17321347faf088b006c6abc2f4d332606cb91

[xnimorz]

Thank you for the issue and the example!

Also, I've fixed the example by updating the version of use-debounce: https://codesandbox.io/s/hungry-architecture-4z46m?file=/pages/index.js (so that it works now)

[bzztbomb]

https://github.com/vercel/next.js/issues/12753 is an example where it'd be useful to disable fast refresh

[Lwdthe1]

It'd be great if we could disable this. I want to use the new NextJs, but I don't want to go through all my components and add names to my anonymous functions ...

[timneutkens]

@Lwdthe1 You can run this codemod to update your codebase: https://github.com/vercel/next-codemod#name-default-component

[weyert]

Yes, is there any update for this? Using Fast Refresh with IE11 can sometime be beneficial to be able to disable it; as Fast Refresh can make IE11 unresponsive is my experience.

[mlynch]

Here's an issue I found using Pullstate (https://lostpebble.github.io/pullstate/). On fast-refresh the store will not update so the input value will not change.

Repro:

import Head from 'next/head'
import { Store } from 'pullstate';
import { useCallback, useState } from 'react'

const store = new Store({
  value: 'hello'
});

export default function Home() {
  const value = store.useState(s => s.value);

  const updateValue = useCallback((v) => {
    store.update(s => {
      s.value = v;
    });
  }, [store]);


  return (
    <div className="container">
      <input type="text" value={value} onChange={e => updateValue(e.target.value)} />
    </div>
  )
}

[gaearon]

Hey folks, sorry to hear that Fast Refresh has been occasionally frustrating. I don't think we've seen any case of the Fast Refresh logic itself being broken in React, but it's definitely true not all libraries are 100% compatible with its constraints today.

However, it so happens that the constraints of Fast Refresh are similar (and slightly stricter) than the existing StrictMode, so getting StrictMode-compatible is a good first step anyway! (For example, pullstate which was just referenced above is not: https://github.com/lostpebble/pullstate/issues/60.)

Another important note is that some of the upcoming React features will take advantage of the same set of constraints. So it's not just about "fixing a library for Fast Refresh" but also about making it compatible with powerful features like built-in animation support which we may add in the following couple of years.

We have documented Fast Refresh constraints here and there's another detailed explanation here. I understand the frustration of having to adjust your code to work within these constraints, but it makes your library more resilient overall, and creates a lot of benefit in the long run.