[🐞] Context does not exist after SSR and navigating to a new page

[DustinJSilk]

Which component is affected?

Qwik City (routing)

Describe the bug

After providing a context from the root component, it no longer exists when navigating to a new page.

The following error is thrown:

Actual value for useContext() can not be found, make sure some ancestor component has set a value using useContextProvider() '...' Error: Code(13): Actual value for useContext() can not be found, make sure some ancestor component has set a value using useContextProvider()

Reproduction

https://stackblitz.com/edit/qwik-starter-8f1jai

Steps to reproduce

• Provide a context on the root component (or from within a component that wraps around QwikCityProvider).
• Navigate to a new page
• Call useContext from the new page
• Observe an error in the console

System Info

System:
    OS: macOS 12.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 109.90 MB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 16.17.0 - ~/.nvm/versions/node/v16.17.0/bin/node
    Yarn: 1.22.18 - /usr/local/bin/yarn
    npm: 7.13.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 107.0.5304.110
    Firefox: 107.0
    Safari: 15.1
  npmPackages:
    @builder.io/qwik: ^0.14.0 => 0.14.0 
    @builder.io/qwik-city: ^0.0.125 => 0.0.125 
    vite: 3.2.4 => 3.2.4

Additional Information

No response

[bolt-new-by-stackblitz[bot]]

Start a new pull request in StackBlitz Codeflow.

• qwik-starter-8f1jai (Open reproduction)

[zanettin]

Hi @DustinJSilk Thanks for providing a repro 🙏 I quickly had a look at it and on the /flower route i do get the value of the test context as expected. I do have some issue navigating to the flower route on stackblitz but that seems to be related to another issue.

Can you confirm that?

[DustinJSilk]

Thanks for taking a look @zanettin ! This is definitely happening for me. You can see it happening in the below recording. I've also tried with the latest versions. This is in Chrome 107.0.5304.110 (Official Build) (x86_64)

[zanettin]

@DustinJSilk thanks once again for the recording and info 🙏 looks like this issue is caused on SPA navigations using the <Link /> component (which is wrapped in the example around the blow my mind button) 👍 If you change it to a regular <a>-tag which lets qwik act as MPA, the context is available as expected on my end. Hope smb from the core team can have a look at it 🙏

[DustinJSilk]

@zanettin yes, it's expected to work as an SPA. This issue has been assigned and added to a milestone, it's also a major bug, so it should get fixed soon

[zanettin]

@DustinJSilk all good. don't get me wrong. my comment was just to outline where the context issue occurs. it's not within the MPA logic of qwik but during SPA navigations. just tried to limit the scope of the issue and not questioning if and with which prio it should get fixed 😃

[DustinJSilk]

Providing a context in a layout allows you to shared it across routes.

I'm sure people will still expect contexts provided above the QwikCityProvider and RouterOutlet to persist, but there is a work around in the meantime.

[saeedhbi]

This is happening to me too. I'm updating the path of navigation and after some continuous updates, I'm getting this error for all contexts I have.

Qwik Version: 0.15.2 Qwik-City Version: 0.0.128

[kazerlelutin]

Same thing for me. But it's work for unmount layouts context.

[shairez]

I agree, this is a serious issue for anyone trying to build any non MPA app (that preserves state between page transitions)

@manucorporat FYI - I just double checked this

It happens indeed on SSR and only with <Link> and for me it even happens when I add the useContextProvider inside of the layout.tsx ... and for some reason it doesn't happen when I manually "track" the value of the context.

hypothesis 1: The context is being "dynamically tree shaken out" because Qwik can't see that the page that is behind the <Link> components (maybe because it's not part of the initial SSR, but dynamically loaded afterwards)

hypotheses 2: The context "up the tree" lookup avoids looking for elements that got added dynamically added after the initial SSR

[DustinJSilk]

This issue has come up again for me - i'm trying to expose environment variables with process.env. which only exist on the server, so I need to make them available with a context which gets lost when navigating and cant be provided in a layout because it will load process.env in the browser which isnt possible.

[DustinJSilk]

Okay ive found a work around to my issue. I can provide env variables in the root, then provide them again in the first layout. This was the calls to process.env. are rendered on the server, and on the client the state is shared through the second context provider.

Bit hacky but seems to work so far :)

[Dindaleon]

This is a major bug. I am trying to build a site but can't proceed until this is fixed. Is this being worked on? I really like Qwik!

[doksara]

This still wasn't fixed? After 2 months? I thought this was major bug

[manucorporat]

Fixed! https://github.com/BuilderIO/qwik/commit/c598bd38b0099b327c2224885d6fc4787114d84b

[DustinJSilk]

Thank you @manucorporat !!

[Dindaleon]

Fixed! c598bd3

Awesome! Can't wait to try it out.

[atinylittleshell]

@manucorporat This seems still a problem in dev mode where there's no ssr. When ssr is disabled and you visit any route that's not root then this problem happens again.

[DustinJSilk]

@atinylittleshell your comment might get missed here, I’d suggest creating a new issue with a way to reproduce the problem