Fast Refresh had to perform a full reload

[por14571-jochoa]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

What browser are you using? (if relevant)

Google Chrome 102.0.5005.115

How are you deploying your application? (if relevant)

next run dev

Describe the Bug

When data is sent to the service and a context that handles the entire application is updated, the system does not change the page but reloads itself, deleting everything in the provider (react)

Expected Behavior

I hope you go to the next screen which is indicated by the router.push(urlRelative, url)

Link to reproduction

/None

To Reproduce

Is project in development

_NEXT-1355

[rtpa25]

facing the same issue when with apollo client

[dalalRohit]

yeah, I am facing the same issue. While doing client-side navigation, the page gets fully refreshed automatically.

[RyousukeUchino]

I don't know if this is a similar issue, but sometimes the same error would occur.

When this occurred, I deleted the .next directory and did yarn dev again and this error did not occur anymore.

[dalmasonto]

Same error occurs just by having routing in my next js app, help solve

[dalmasonto]

The error was caused by exporting a react component in lowercase ie const index = () => {return <></>}
Renaming to const Index = () => {return <></>} solved it.

[DanPresa]

The error was caused by exporting a react component in lowercase ie const index = () => {return <></>} Renaming to const Index = () => {return <></>} solved it.

I don't think this solve the issue because the issue starts when you run yarn/npm run dev

[ethyaan]

Hi,
Fresh install of the nextjs is giving me the same error

I have no idea what is this

[dalmasonto]

Hi, Fresh install of the nextjs is giving me the same error

I have no idea what is this

Have you changed anything in the code?

[dalmasonto]

Hi, Fresh install of the nextjs is giving me the same error

I have no idea what is this

If you are using typescript for your project, remember to set your pages to use either .tsx or .ts. Also, if a page is returning nothing or the page is returning a function which is not a react component the error could rise

[ethyaan]

Hi, Well, extensions are tsx, and also, it's a valid React component. And, as I mentioned, it's a fresh install without any modification, so you can install it and see for yourself how it behaves. I couldn't understand why or what this was for. The error is not explicative.

[Youssef-Durgham]

same error here.

[DanPresa]

Hi, Fresh install of the nextjs is giving me the same error
I have no idea what is this

If you are using typescript for your project, remember to set your pages to use either .tsx or .ts. Also, if a page is returning nothing or the page is returning a function which is not a react component the error could rise

typescript has nothing to do, because when you create a project without typescript throws the same error

[ethyaan]

I really tried to figure this out but couldn't find anything and now I just tried,
you don't believe me it works and i didn't touch a thing;
always weird things in js/ts world

[DanPresa]

I really tried to figure this out but couldn't find anything and now I just tried, you don't believe me it works and i didn't touch a thing; always weird things in js/ts world

If it is the first time you are running it it's normal.
Shut down the cli and try to run it once again.

[Mood-al]

I updated my version from next 13.4.6 to 13.4.12 because there were some issues with SWR package

and this problem started to appear in my project i don't understand why this is happening since in 13.4.6 version it was working just fine!!
I tried to downgrade to 13.4.9 version and the same problem was there!

[Mood-al]

I think i figured out why the problem is happening in my case! since i'm using the page router and using api routes with it, and in those api routes i'm exporting a nameless function so when i tried to name it the problem gone and in Next 13 they named them like so
export default async function handler(req, res) {}

[leikoilja]

Same issue only on chrome (even with all plugins disabled).

• firefox works file
• chrome in incognito works wine

my walk-around solution:
phew, after long time of fighting with the issue, thanks to @dycw what helped is to change next js dev server to run on port 3010. Weird magic but it helped.

[Humed-Muhammad]

Updating nextjs package to 13.4.19 (latest version) solved the problem for me

[jessedelira]

Hello, guys, just found out what is happening with such an install, it is not a bug, it is something critical in next js, and for my take it is appearing on v13, I guess this is a new check. I have done some more explanation here https://youtu.be/QF1vPoDY9kg The full reload updates your UI with what your server has incase you have an open tab pointing to port 3000 when you run your app

This was the reason for me, thank you so much!

[bhavesh-chaudhari]

Issue got fixed when I upgraded from [email protected] to latest

[MinSeok0901]

13.5.3에서도 여전히 발생합니다.

✓ Ready in 2.4s
⚠ Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload
✓ Compiled / in 765ms (351 modules)

[jessedelira]

13.5.3에서도 여전히 발생합니다.

✓ Ready in 2.4s

⚠ Fast Refresh had to perform a full reload. Read more: https://nextjs.org/docs/messages/fast-refresh-reload

✓ Compiled / in 765ms (351 modules)

Did you have a window open with localhost:port when the application is running locally?

[sentience]

Because this specific warning has several possible causes (most of which are documented at the URL cited in the message), this issue thread is a tangle, with different people trading experiences of and solutions for completely different root-causes of this message. I suggest this issue be closed in favour of more scenario-specific issues (in other words, please report with a reproducible test case).

For what it's worth, in our project we are only seeing this message when we stop and then restart the dev server, with the app actively displayed in an open browser. Here are the reproduction steps:

1. next dev
2. Open the app in Chrome.
3. Back in your Terminal, Ctrl-C to stop the dev server. The browser loses its Web Sockets connection to the dev server.
4. next dev again to launch a new instance of the dev server.
5. The page already open in the browser re-establishes its connection to the dev server, but tries and fails to load a now-obsolete “hot-update” manifest URL (e.g. http://localhost:3000/_next/static/webpack/7934fb62ffa750b9.webpack.hot-update.json). As a fallback, the app (correctly) performs a full reload.
6. The dev server prints the warning: "Fast Refresh had to perform a full reload."

I believe it is normal for Fast Refresh not to be able to live-update the page that was originally loaded from a different running instance of the dev server, and for it to fall back to a full reload. That this produces a warning in the dev server console is not unreasonable, but is perhaps more confusing than useful.

The real issue here seems to be that the information provided at the documentation URL cited in the message is misleading, since it does not mention this potential cause: that an open browser displaying the app generated by a previous instance of the dev server cannot Fast Reload from a newly-launched dev server.

If the maintainers would accept the contribution, I'm happy to open a PR against that documentation page to add this potential cause to the list.

[lveillard]

Because this specific warning has several possible causes (most of which are documented at the URL cited in the message), this issue thread is a tangle, with different people trading experiences of and solutions for completely different root-causes of this message. I suggest this issue be closed in favour of more scenario-specific issues (in other words, please report with a reproducible test case).

For what it's worth, in our project we are only seeing this message when we stop and then restart the dev server, with the app actively displayed in an open browser. Here are the reproduction steps:

1. next dev
2. Open the app in Chrome.
3. Back in your Terminal, Ctrl-C to stop the dev server. The browser loses its Web Sockets connection to the dev server.
4. next dev again to launch a new instance of the dev server.
5. The page already open in the browser re-establishes its connection to the dev server, but tries and fails to load a now-obsolete “hot-update” manifest URL (e.g. http://localhost:3000/_next/static/webpack/7934fb62ffa750b9.webpack.hot-update.json). As a fallback, the app (correctly) performs a full reload.
6. The dev server prints the warning: "Fast Refresh had to perform a full reload."

I believe it is normal for Fast Refresh not to be able to live-update the page that was originally loaded from a different running instance of the dev server, and for it to fall back to a full reload. That this produces a warning in the dev server console is not unreasonable, but is perhaps more confusing than useful.

The real issue here seems to be that the information provided at the documentation URL cited in the message is misleading, since it does not mention this potential cause: that an open browser displaying the app generated by a previous instance of the dev server cannot Fast Reload from a newly-launched dev server.

If the maintainers would accept the contribution, I'm happy to open a PR against that documentation page to add this potential cause to the list.

I would add that even better than having nice docs explaining all the 10 causes for this error, would be to catch which one of triggers is fired and inform about it.

Obviously "hey, you are exporting one component in camelCase in this file in this line" is easier to fix than "hey, one of these 4 issues exist somewhere in your codebase"

[moarief]

Because this specific warning has several possible causes (most of which are documented at the URL cited in the message), this issue thread is a tangle, with different people trading experiences of and solutions for completely different root-causes of this message. I suggest this issue be closed in favour of more scenario-specific issues (in other words, please report with a reproducible test case).
For what it's worth, in our project we are only seeing this message when we stop and then restart the dev server, with the app actively displayed in an open browser. Here are the reproduction steps:

1. next dev
2. Open the app in Chrome.
3. Back in your Terminal, Ctrl-C to stop the dev server. The browser loses its Web Sockets connection to the dev server.
4. next dev again to launch a new instance of the dev server.
5. The page already open in the browser re-establishes its connection to the dev server, but tries and fails to load a now-obsolete “hot-update” manifest URL (e.g. http://localhost:3000/_next/static/webpack/7934fb62ffa750b9.webpack.hot-update.json). As a fallback, the app (correctly) performs a full reload.
6. The dev server prints the warning: "Fast Refresh had to perform a full reload."

I believe it is normal for Fast Refresh not to be able to live-update the page that was originally loaded from a different running instance of the dev server, and for it to fall back to a full reload. That this produces a warning in the dev server console is not unreasonable, but is perhaps more confusing than useful.
The real issue here seems to be that the information provided at the documentation URL cited in the message is misleading, since it does not mention this potential cause: that an open browser displaying the app generated by a previous instance of the dev server cannot Fast Reload from a newly-launched dev server.
If the maintainers would accept the contribution, I'm happy to open a PR against that documentation page to add this potential cause to the list.

I would add that even better than having nice docs explaining all the 10 causes for this error, would be to catch which one of triggers is fired and inform about it.

Obviously "hey, you are exporting one component in camelCase in this file in this line" is easier to fix than "hey, one of these 4 issues exist somewhere in your codebase"

Using the ESLint React reccommended plugin or just the single rule would prevent this from happening: https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/react-in-jsx-scope.md

But I agree, more information would be beneficial in this case as I have the same problem, checked all files and removed other exports from a react component file... so don't see the issue, unless it might be the .scss files for me?

Or might be because I am using a proxy?..

[ricardo-fnd]

I get this message when I rewrite from an app using app folder to a app using pages folder, and in this last case, it enters in a loop. You can get more info here #59580

[samcx]

Hi everyone!

I will be moving this issue to our Discussions, to echo what was suggested here.

We encourage folks to file bugs outside of this thread detailing the exact issue, with a and details for how to consistently reproduce the issue! Tracking each of these Fast Refresh issues separately will make it easier for us to efficiently (and less noisy) triage.

Happy 2024!

[essambarghsh]

I encountered this issue with a Next.js TypeScript component that was triggering full page reloads during Fast Refresh instead of performing hot updates. This significantly slowed down the development experience and caused loss of component state.

Cause

The problem stemmed from how I was handling state and side effects in my component:

1. I was using a useState hook with a nullable boolean (null | boolean) to track a certain condition.
2. The initial state determination was happening synchronously during the component's render.
3. I had conditional rendering based on this state being null.
4. Frequent checks of a browser API (similar to window.innerWidth) were causing unnecessary re-renders.

These factors combined were confusing React's Fast Refresh mechanism, causing it to fall back to full reloads.

Solution

I refactored the component to address these issues:

1. Removed the null state from the condition check:

   const [someCondition, setSomeCondition] = useState(false);

2. Moved the condition checking logic outside useEffect and memoized it:

   const checkCondition = useCallback(() => {
     setSomeCondition(/* check condition */);
   }, []);

3. Simplified the useEffect for condition checking:

   useEffect(() => {
     checkCondition();
     // Set up event listener if needed
     return () => {/* Clean up event listener if needed */};
   }, [checkCondition]);

4. Memoized event handlers with useCallback to prevent unnecessary re-creation.

5. Removed conditional rendering based on the state being null.

6. Optimized effects to run only when necessary, reducing side effects.

These changes significantly improved the component's compatibility with Fast Refresh. By reducing state updates, eliminating conditional rendering based on nullable state, and optimizing effects and callbacks, the component became more stable and stopped triggering full page reloads during development.

The key takeaway is to be mindful of how we handle state that depends on values outside of React's control (like browser APIs) and to optimize our components to reduce unnecessary re-renders and effects. This approach not only solves Fast Refresh issues but also leads to better-performing React components overall.

[BrunoBorges12]

he issue was due to @next/bundle-analyzer. I temporarily removed it.