Closed timfee closed 2 years ago
I confirmed this problem doesn't happen if you remove withAuthUser
from the page.
I tried breaking useAuthUser
into separate modules in case the two exports (the context provider and useAuthUser
hook) caused this issue, but that didn't fix it.
Very much welcome help on this!
So this is interesting. HMR seems to work for my project I'm tinkering with: https://github.com/timfee/slot.fyi.
Highlights:
<Layout>
<Component {...pageProps} />
</Layout>
import { FC } from 'react'
import { useAuthUser, withAuthUser } from 'next-firebase-auth'
const Layout: FC = ({ children }) => { // snip
return ( <> { / snip / } {!auth.firebaseUser && auth.clientInitialized && (
)}
<main className="max-w-4xl px-6 mx-auto mt-8">{children}</main>
</>
) }
export default withAuthUser({})(Layout)
* an actual inner page is:
```ts
import { Profile } from '@/components/settings/account/Profile'
import { CalendarList } from '@/components/settings/calendars/CalendarList'
import { useCollection } from '@/hooks/useCollection'
import { useDocument } from '@/hooks/useDocument'
import firebase from '@/lib/firebase'
import { UserType } from '@/types/user'
import {
AuthAction,
getFirebaseAdmin,
useAuthUser,
withAuthUser,
withAuthUserTokenSSR
} from 'next-firebase-auth'
import { FC } from 'react'
const Account: FC<any> = ({
meta
}: {
meta: {
uid: string
displayName: string
emailAddress: string
photoUrl: string
}
}) => {
const authUser = useAuthUser()
// snip
return (
<>
<Profile
data={typeof profileData === 'undefined' ? null : profileData.data()}
/>
</>
)
}
export const getServerSideProps = withAuthUserTokenSSR({
whenUnauthed: AuthAction.REDIRECT_TO_LOGIN
})(async ({ AuthUser }) => {
const UserRecord: UserType = (
await getFirebaseAdmin().firestore().doc(`/users/${AuthUser.id}`).get()
).data()
console.log(UserRecord)
const {
uid,
meta: { displayName, emailAddress, photoUrl }
} = UserRecord
return {
props: {
meta: {
uid,
displayName,
emailAddress,
photoUrl
}
}
}
})
export default withAuthUser({})(Account)
I have no idea why this works, but wanted to share.
Spent 5 hours on this, and while I don't have a solution, I think I've homed in on the issue (and it's a mega issue if I'm correct)...
Basically, if you reduce withAuthUser
to this minimal function:
const withAuthUser = ({} = {}) => (ChildComponent) => {
/* 1 */ const WithAuthUserHOC = (props) => <ChildComponent {...props} /> // Doesn't work
/* 2 */ const WithAuthUserHOC = ChildComponent // Works
return WithAuthUserHOC
}
Then Fast Refresh does not work with /* 1 */
, but it does with /* 2 */
.
This is super odd. So odd, that my immediate suspicion was that something's wrong with the build/transpilation.
So I've put webpack in development
mode in order to see what the transpiled code under build
looks like and boom... /* 1 */
was suddenly working.
Now this is the first library I see that exports a node distribution (specifically of React components) the way this one does (using webpack). build/index.node.js
is littered with webpack stuff that is completely unnecessary - either babel
alone or rollup
would normally be used in these cases (and we should also mention esm
distributions rather than CommonJS, specifically if this is a library for NextJS, which uses WebPack where esm
has many benefits).
Anyhow, if indeed someone confirms that Fast Refresh works when webpack is in development
mode, I strongly suspect there is something wrong with the way this library is built for node.
Also part of the investigation, I had NextJs
in example
building the library code directly. When I did this, I got the blue NextJS warning that isClientSide
is not Fast Refresh compliant (It does have an unnamed default export: export default () => typeof window !== 'undefined'
).
OK. I know what the issue is.
It is the fact that the library is split distributed with client methods under "browser"
in package.json
and server under "main"
. This seems to confuse fast refresh (my theory is that when it tries to replace the modified file it sends to the client the server version of the file, but it can't find it on the client because the client module is not in the same format).
What I've done:
esm
build./auth
page).I'm going to create a new issue regarding how this library is built, with a proposal for a "uni-build", this will have many benefits, but it'll be a breaking change (change to import location for any server related functions).
@Izhaki I've actually hit the same issue without even using this library.
As you mentioned, anytime you use a HOC on a next.js page it doesn't work. Here is a quick demo: https://stackblitz.com/edit/nextjs-77e7qw?file=pages/index.js
Any other thoughts or updates? Is this NextJS issue? Or there is a different way to a user be authenticated that might work better?
This bug appears to be fixed on v1.x with peer dependencies:
"firebase": "^9.9.1",
"firebase-admin": "^11.0.0",
"next": "12.2.3",
"react": "18.2.0",
"react-dom": "18.2.0",
I attempted to reproduce the problem here, but HMR is working as expected: https://github.com/gladly-team/next-firebase-auth/pull/550
It was fixed in v1.0.0-canary.12, possibly because of changing index.server.js to not import from index.js in #512—but we have not investigated the underlying reason. (Unintentional bug fix? We'll take it!)
The bug persists on v0.x: https://github.com/gladly-team/next-firebase-auth/pull/551
Closing this!
Hey! Seems like there might have been a regression here. I tested the PR that confirmed the issue was fixed and it worked as expected. However, with later versions of next-firebase-auth I'm still seeing the issue. Tested the following:
The only change I made to the example was updating withAuthUser
to withUser
. Do you want to continue the discussion here or should I open a new issue?
I also tried downgrading nextjs on the 1.0.0
branch but HMR still didn't work
Version ^1.0.0-beta.0
Next.js 12.2.3
Firebase 9.16.0
firebase-admin ^11.9.0
@jhnj A new issue would be great, thanks!
Description
When editing a
Component
that is wrapped withwithAuthUser({})
, React performs full-page refreshes; for example:Version
Using the example's version: "0.13.0-alpha.4"
To Reproduce
gladly-team/next-firebase-auth
repo as isexamples
directoryAdditional context
The warning in the console:
Expected behavior
If this is unavoidable without additional configuration, it'd be awesome to capture the necessary steps somewhere in the example or in the doc. And if it's totally unavoidable, it might be a good FAQ note :)