Skip to content
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

Context declared in _app undefined during SSR in dev #18917

Closed
ljosberinn opened this issue Nov 7, 2020 · 12 comments · Fixed by #20652
Closed

Context declared in _app undefined during SSR in dev #18917

ljosberinn opened this issue Nov 7, 2020 · 12 comments · Fixed by #20652
Assignees
Labels
kind: bug Confirmed bug that is on the backlog
Milestone

Comments

@ljosberinn
Copy link
Contributor

ljosberinn commented Nov 7, 2020

Bug report

Describe the bug

Running into basically this issue #4194 here sometimes, only in dev.

It's a fresh app, not much happening as of yet. A single context provider wrapping Component in app, and a index page using the context through a custom hook.
The contexts initial value is null, but its filled through the provider. The custom hook throws on empty context value.

To Reproduce

Repo: https://github.com/ljosberinn/AuctionCraftSniper/blob/518d537557/src/pages/_app.tsx

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Check that repo out (branch next)
  2. yarn dev
  3. click the link in the console to localhost:3000
  4. first render will work
  5. F5, crashes

Expected behavior

Context should not be empty.

Screenshots

_app:
image

AuthContextProvider rendering with a value present
image

index calling hook:
image

Breakpoint where error is thrown:
image

Call Stack in VSCode Debugger:
image
Call Stack in Browser:
image
Call Stack in Console:
image

System information

  • OS: Win 10
  • Browser (if applies) Chrome
  • Version of Next.js: latest
  • Version of Node.js: 15.0.1
@ljosberinn ljosberinn added the template: bug A user has filled out the bug report template. Issue needs triaging label Nov 7, 2020
@brandonbloom
Copy link

I'm seeing the same issue with similar usage. The same code worked with Webpack 4 prior to upgrading to Webpack 5, if that information provides at all useful for debugging.

@timneutkens timneutkens added kind: bug Confirmed bug that is on the backlog type: needs investigation and removed template: bug A user has filled out the bug report template. Issue needs triaging labels Nov 23, 2020
@timneutkens timneutkens added this to the iteration 14 milestone Nov 23, 2020
@PepijnSenders
Copy link
Contributor

I've been breaking my brain on this for some time already as well, we're seeing exactly the same issue in our project. @timneutkens let me know if you need help with reproducing this.

@PepijnSenders
Copy link
Contributor

I think this is a very simple, yet effective reproduction of the issue: https://github.com/stefanprobst/next-webpack5-issue

@bscaspar
Copy link

bscaspar commented Dec 24, 2020

I believe I am running into something similar (hard to quite pin it down) when navigating from one page to another that use the same context. The first page, /create/account, checks the users session in getServerSideProps and passes it as pageProps to _app.ts where it is then passed to the Provider and used as the initial state arg for useReducer. So far so good, at this point the context contains the user session data.

The second page, /create/page, uses the user session data from the same context provider. It's a new page so the state and dispatch values are undefined at first render. However, the context does not re-initialize. When calling the reducer like this, the initState function is simply not called when this second page renders:

const [state, dispatch] = React.useReducer(reducerFunc, {...session}, initState);

At this point, the state object exists, but it has empty values for it's properties.

If I simply navigate directly to the second page, there is no issue. The user session is initialized the same way it is on the first page.

It seems like the context is persisting across these two pages (via _app.ts) but the data within the context is not. I can work around this by updating the state with the user session info from getServerSideProps immediately before rendering the provider on the second page, but this feels a bit fragile.

@ijjk
Copy link
Member

ijjk commented Jan 1, 2021

HI, this is updated in the latest version of Next.js v10.0.5-canary.7, please update and give it a try!

@PepijnSenders
Copy link
Contributor

PepijnSenders commented Jan 4, 2021

@ijjk I'm still seeing some issues;

yarn why webpack
├─ next@npm:10.0.5-canary.9
│  └─ webpack@npm:5.11.1 (via npm:5.11.1)
│
└─ next@npm:10.0.5-canary.9 [e7565]
   └─ webpack@npm:5.11.1 [2986d] (via npm:5.11.1 [2986d])

When I add <h1>hello world</h1> to a page, the old setup triggers an HMR refresh and it's updated within a millisecond. On the new setup, it takes around 15 seconds to recompile the entire page and update it.

I will check the context bug as well, haven't spotted it yet, but with these kinds of refresh rates it's also not really viable for us to update.

@PepijnSenders
Copy link
Contributor

The context issue seems fixed, any clue why HMR could be broken in this upgrade?

@ijjk
Copy link
Member

ijjk commented Jan 5, 2021

@PepijnSenders we haven't heard any other reports of the HMR time increasing as you described above, can you provide a reproduction on a fresh issue for the HMR time increase you are seeing so we can investigate it closer?

@PepijnSenders
Copy link
Contributor

Actually, HMR isn't working at all it just refreshes. I can try to repro, but isolating the issue will be hard because this page is huge! 😄

@PepijnSenders
Copy link
Contributor

PepijnSenders commented Jan 5, 2021

@ijjk opened a new issue to track this: #20760. Working on isolating the issue in the meantime and seeing if removing all the warnings fixes the compile time. If you have any ideas of points where I can debug this, please let me know!

@PepijnSenders
Copy link
Contributor

Removing the warnings didn't make it faster 😢

@balazsorban44
Copy link
Member

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.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind: bug Confirmed bug that is on the backlog
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants