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.

Sign up for GitHub

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

Jump to bottom

Svelte 5: suddendly from v121 I cannot use tanstack/query anymore #11429

Closed
frederikhors opened this issue May 2, 2024 · 7 comments · Fixed by #11438
Closed

Svelte 5: suddendly from v121 I cannot use tanstack/query anymore #11429

frederikhors opened this issue May 2, 2024 · 7 comments · Fixed by #11438
Assignees
@dummdidumm
Milestone
5.0

Comments

@frederikhors
Copy link

frederikhors commented May 2, 2024 •
edited

Describe the bug

Suddendly from v121 I cannot use tanstack/query anymore

Uncaught (in promise) Error: No QueryClient was found in Svelte context. Did you forget to wrap your component with QueryClientProvider?
    at getQueryClientContext (chunk-IPFQYTE6.js?v=d25fe8b0:44:11)
    at useQueryClient (chunk-IPFQYTE6.js?v=d25fe8b0:73:10)
    at useIsFetching (chunk-IPFQYTE6.js?v=d25fe8b0:186:18)
    at Navbar.svelte:13:18
    at untrack (chunk-LAN3S4TN.js?v=d25fe8b0:1467:12)
    at Object.fn (chunk-LAN3S4TN.js?v=d25fe8b0:421:5)
    at execute_reaction_fn (chunk-LAN3S4TN.js?v=d25fe8b0:1054:22)
    at execute_effect (chunk-LAN3S4TN.js?v=d25fe8b0:1171:20)
    at create_effect (chunk-LAN3S4TN.js?v=d25fe8b0:368:7)
    at render_effect (chunk-LAN3S4TN.js?v=d25fe8b0:443:10)

Obviously nothing changed in my code from 120 to 121.

Severity

blocking all usage of svelte
@dummdidumm
Copy link
Member

Please provide a reproduction

@dummdidumm dummdidumm added the awaiting submitter needs a reproduction, or clarification label May 2, 2024
@frederikhors
Copy link
Author

It's a default tanstack/query default app. I'll post a reproduction in a few hours...

@alesvaupotic
Copy link

No repro here but I am also getting hydration_mismatch related to Svelte context with 121. Can't pinpoint it yet but 120 works as expected.

@alesvaupotic
Copy link

https://github.com/alesvaupotic/svelte-5-next-121-context Basic repro here. Replacing next-120 with next-121 breaks it for me.

@Thiagolino8
Copy link

reproduction

@alesvaupotic
Copy link

Apologize for hijacking the thread, @frederikhors, I just thought we don't need another bug report as ours are related.

@dummdidumm dummdidumm removed the awaiting submitter needs a reproduction, or clarification label May 2, 2024
@dummdidumm dummdidumm added this to the 5.0 milestone May 2, 2024
@rgieseke rgieseke mentioned this issue May 2, 2024
Merged
@dummdidumm
Copy link
Member

dummdidumm commented May 2, 2024 •
edited

My guess is that #11401 is the culprit though I haven't validated it yet. Update: Confirmed this is the culprit. Problem is that the snippet resets the current component context to that of the component it is rendered in, which fucks up the context chain:

<!-- inside App.svelte -->

<Provider> <!-- context should be this ... -->
  <Inner /> <!-- but because this is a snippet under the hood which resets the current component context, the context becomes App.svelte -->
</Provider>

@dummdidumm dummdidumm self-assigned this May 3, 2024
dummdidumm added a commit that referenced this issue May 3, 2024
@dummdidumm
fix: prevent ownership validation from infering with component context
d87c139 
Ownership validation had a false positive when rendering a component as slotted content of another component. To fix this, #11401 did set the current component context to the context the snippet was declared in, not to the context it is rendered in. This was flawed because it means that component context was altered in a way that setContext/getContext failed because the parent chain was incorrect. This fixes that by introducing a separate global (dev time only) which tracks the component function the ownership needs.

fixes #11429
@dummdidumm dummdidumm mentioned this issue May 3, 2024
Merged
5 tasks
dummdidumm added a commit that referenced this issue May 3, 2024
@dummdidumm
fix: prevent ownership validation from infering with component context (
6e5ab2e 
#11438)

Ownership validation had a false positive when rendering a component as slotted content of another component. To fix this, #11401 did set the current component context to the context the snippet was declared in, not to the context it is rendered in. This was flawed because it means that component context was altered in a way that setContext/getContext failed because the parent chain was incorrect. This fixes that by introducing a separate global (dev time only) which tracks the component function the ownership needs.

fixes #11429
@dummdidumm dummdidumm mentioned this issue May 3, 2024
Open
@mikiadev mikiadev mentioned this issue May 3, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dummdidumm dummdidumm

Labels
None yet
Projects
None yet
Milestone
5.0
Development

Successfully merging a pull request may close this issue.

fix: prevent ownership validation from infering with component context sveltejs/svelte
4 participants
@alesvaupotic @dummdidumm @frederikhors @Thiagolino8