Urql now has a new package @urql/next which adds support for the app-router part of Next.JS. It has an export for both server components as well as the usual ssr workflow.
An example: github.com/urql-graphql/urql…
In the example above, if B is also code split, you have to load the code for B before it can start fetching the data, so you'll get a double waterfall. On the server, this is fine, on client page transition, not so much.
So I wouldn't throw away my prefetches just yet. 5/5
With this solution, you now have a client side request waterfall which hurts performance, especially when the user has high latency (which happens all the time).
This gets worse the more nested useQuery you have, and gets even worse when you factor in code splitting too. 4/5
With this kind of prefetch-less solution, if two components <A><B /></A> both useQuery, you have a waterfall and for the server render that's usually fine, BUT, what happens when you do a client side page transition? 3/5
This kind of "just use useQuery wherever, no prefetching needed" is great for DX, but can be terrible for performance. Why?
SCs and app router works by mostly eliminating waterfalls, and when they can't be eliminated, they at least guarantee they always happen on the server. 2/5
This is very cool, and useful for some cases, and kudos to everyone involved, truly great job, but I have some reservations against this kind of prefetch-less data fetching solution I have to note.
This reintroduce waterfalls into SSRd apps that has not had them previously. 1/5
📢 Yesterday, we released an experimental react-query-nextjs package for the app directory. Wrap your app in the <ReactQueryStreamedHydration> component to enjoy direct useQuery fetches on the server with suspense, which streams to the client 🎉
Example: tanstack.com/query/v5/docs/r…
I'll be talking at React Advanced London in October! 🥳
Since the tweet can be read two ways, let me clarify that React Query will definitely be part of the journey, not something we migrate away from. 😀
Let's embark on a migration journey from the older #NextJS pages router & React Query to something even better🚀
In this talk,🗺️@ephemjs will provide a practical roadmap with actionable steps, taking you from where you started to a shippable & superior solution.
See you there!
Hard agree. I see so much purely negative criticism and so little constructive.
The misinterpreting motivations one is the worst. If you have just a tad of empathy it's so easy to see how they are a tiny team trying to do tons and it just takes time. Stop being so entitled.
I lol'd pretty hard at this comment from @ephemjs 😂
ALT code reads:
cache.subscribe((event) => {
comment reads:
Side effect in render which directly mutates state and also doesn't unsubscribe? Hat-trick, I like it. 😉
Excited to say I'm now considering new job opportunities! I was an early user of React, managed the team at FB, and recently finished a VP Eng role at Humu.
Now I'm looking to join a diverse, kind, hypercompetent team, with a role where I can empower and upskill engineers.
Doesn't always apply of course, like when you have multiple generics you might want to name them for clarity etc, but good rule of thumb.
In general though, people should name more generics..
I can't find the tweet now, but @TkDodo recently had a good point about how using e vs error/event depends on the distance between declaration and use. Just realised this goes for TS generics too.
If you only use the generic in the function declaration, T is fine, otherwise not.
It's been an _amazing_ 2 days at @reactsummit :
- Met @phry (RTK co-maintainer) in person after 4 years working together :)
- Met @tkdodo , @mweststrate , @ephemjs , @jherr, and many others I've chatted with for years
- My "Debugging JS" talk + live @replayio demo went well!
I'm sorry for not including a whole bunch of lovely people on this list, either I failed catching your full name or couldn't find you on Twitter, please ping me if we talked.
Still parsing so many great discussions and the best part is, there's still another day to go.