-
Notifications
You must be signed in to change notification settings - Fork 26.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document Fast Refresh requirements and troubleshooting #13104
Comments
You may ask why are you exporting something other than your component as default. |
It's expected that Fast Refresh is disabled if you export something that is not a React Component (even a scalar value as shown above). We'll document this in the docs. |
Related: #13024 |
@Timer sorry if this isn't the right place for this question, but is it possible to disable Fast Refresh globally in |
@thadwoodman it is not possible to disable Fast Refresh. Can you elaborate why you'd like to do this? |
I had the very same question and the reason was that full reload is disastrous for us. But I'm pretty sure that if your code comply with (the currently unclear) guidelines, you will not have full reloads. This leaves you with the same behaviour as hmr (before Fast Refresh was introduced), yet with the benefits of Fast Refresh. |
@Timer sure! I'm trying to troubleshoot an error I'm getting on worker in my local dev environment:
After some Googling it seems like this is related to React Refresh and I only started seeing this error after upgrading to Next.js 9.4. I should note that there are other people on my team using the same build and not getting this error. I was just looking for an easy way to turn off Fast Refresh to troubleshoot the issue. |
@Timer looks like issue persists even when I use downgrade Next.js to 9.3, so probably not an issue with Fast Refresh. |
Okay, workaround for reason-react (bucklescript) projects is to make an interface file ( let default: Js.t({.}) => React.element; |
@Timer I am not sure if I fully understand this: So Fast Refresh will only work if my file only exports a default that is a React component, and that has a function with a name? So exporting a default that is a React component, plus exporting some other named exports is not allowed? That's essential what a ReasonReact module file would do // pages/somePage.re
let foo = "hello world";
[@react.component]
let default = () => { <div> </div>}; when transpiled to ES6 will look like this: // pages/somePage.bs.js
import * as React from "react";
function Foo$default(Props) {
return React.createElement("div", undefined);
}
var foo = "hello world";
var $$default = Foo$default;
export {
foo ,
$$default ,
$$default as default,
} |
How can this be? When using Documenting it would be great, I've seen a few setup where people export scalars, like string and such to know whether a page uses SSG or SSR. Doing so would break fast refresh on all pages. 😢 |
I'd like to know the reason of it too. I'm using TypeScript and exporting types in my components and not sure if that triggers a hard refresh? And how about to work with external libraries which export named components not default exports? |
@dohomi Exporting TS types won't trigger a hard refresh, because they're stripped from the bundled JS. Also, it's easy to know if a hard refresh is triggered, because the whole page refreshes. |
@Vadorequest yes I just look for the reason behind it.. I have over 50 components and searching for the needle which forces a page reload instead of fast-refresh.. it would be great if the log would output the files involved which triggers the reload. |
There's no need to find the "needle in the haystack", your components can export things that aren't valid react components as long as at least one component in the parent tree is valid (no additional exports). |
@Timer thanks for clarifying this |
Seems like it's happening when the page has an exported config I.E |
Exporting config does seem like a bug. Can you open a new issue @amiralies? |
@Timer one quick question about this topic: I handle provider/context usually in one file. Like a default export for the Provider and the useContext hook for the particular context. This would lead into a full reload because its a hook and a component being exported, right? That might be the case for me why I am facing the reload |
This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Bug report
Describe the bug
Fast refresh is not working when using named exports alongside default export.
To Reproduce
pages/index.js
and remove export default from your function componentExpected behavior
Fast refresh should work
System information
The text was updated successfully, but these errors were encountered: