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

RFC (next-urql): Support for Next.js app router #3208

Closed
GRA0007 opened this issue May 7, 2023 · 2 comments · Fixed by #3214
Closed

RFC (next-urql): Support for Next.js app router #3208

GRA0007 opened this issue May 7, 2023 · 2 comments · Fixed by #3214
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release

Comments

@GRA0007
Copy link

GRA0007 commented May 7, 2023

Summary

Next.js has just released version 13.4, and with it the new app directory is now stable. I'd like to see next-urql updated to support the new app router, with updated documentation on how to set it up.

Proposed Solution

The existing withUrqlClient HOC function currently accepts a component of type NextPage or NextApp, both of which are no longer relevant with the new app directory. The next-urql package should support the new app directory (with a layout.js file) and ensure that it uses the use client directive where appropriate.

@GRA0007 GRA0007 added the future 🔮 An enhancement or feature proposal that will be addressed after the next release label May 7, 2023
@GRA0007 GRA0007 changed the title RFC: Support for Next.js app router RFC (next-urql): Support for Next.js app router May 7, 2023
@kitten
Copy link
Member

kitten commented May 7, 2023

I'm sorry, but I really don't see the point. I mean, the RFC you've written is also very handwavy, which to me is a further indication that people don't see that GraphQL and server components are conflicting 😅

You can use @urql/core in your server components on the server if you need to fetch GraphQL data.

You can use the client-side React bindings no problem and use the directive and providers yourself on the client-side.

We could mark the entire next-urql library as client-side, but again, that's handwavy on the library's side. In fact, the only reason why the library exists is that it enables SSR in Next, not Server components.
Hence, the directive makes sense for marking component boundaries as client-side or server-side but that doesn't really apply in this case.

The only appropriate way forward here is to "abuse" server-components for client-side rehydration, i.e. rendering on the server and then sending that data to the client, however, I don't even think that makes sense for us to take care of for an early feature like this for which there isn't really enough buy-in right now.

@GRA0007
Copy link
Author

GRA0007 commented May 8, 2023

That's fair, thanks for taking the time to write out your thoughts. I think mainly I'm confused about the role of the SSR exchange and the react-ssr-prepass package, and whether those are needed with Next.js and the new app router. I admit that's a knowledge deficiency on my part, but maybe all that's needed is some documentation on an ideal setup with the new Next.js app directory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants