Fredrik Höglund

Seems harder to work around, guess you would have to wrap the promise-generating API in something like const promise = alwaysSuspendInSSR(() => fetch(…))?

Besides being a bit ugly and not very straightforward to understand I’m sure this has other implications I’m not considering too though.

Only downside I see of this is that with const { promise } = useQuery(…); and use(promise) further down, we’d have to suspend with the ”useBrowserOnly” from the fetch and not the use, unless we build a wrapper around use() or leak calling the hook to userland which defeats the purpose.

React.use(React.isSSRInProgressPromise) 🙃😆

Landing an API that feels right for this might definitely take some thinking and iteration, I’m happy as long as it’s conditional! 🫶

Thanks, I agree. True algebraic effects in JS would be nice.

Do you know if there are any plans for notFound()/redirect() for these same reasons?

So if you prefetch, we render during SSR.

The conditionality would also let us make this behaviour configurable, so existing experiments with fetching in SSR would still work, and we could introduce this in a minor and keep existing behaviour and flip the default behaviour in next major.

For React Query it might be if it had useBrowserOnlyRender({ enabled: true|false }) or equivalent. If that hook does what I think (suspend on server, resolve in browser), we could use it in our useSuspenseQuery _if existing data or promise is missing_ to avoid fetching during SSR.

Isn’t that usually done by transporting the promise to the client, but still resolving it on the server though? Not sure I’ve seen any libs/solutions using infinite promises, so if you know any I would love to take a look!

In Next there is a super secret internal error you can throw to get around this.. 🫣🤫

I would never of course, let’s say I’ve heard it from a friend.

Getting the promise in there is no problem, what I worry about is, is it defined when React(/frameworks?) will stop waiting for that promise and release the stream? Even if stream is released, will request hang on the server and not close?

Btw, I don’t think this was an intentional API design choice. I think when useSuspenseQuery was built it just ended up doing the same thing on the server and client because SSR wasn’t part of the suspense story yet.

I agree with you that erroring by default in SSR would be less of a footgun.

I would also love a way to cleanly suspend on both server and client, but only fetch on the client. I’m not sure if this is possible though. We cant just suspend with an infinite promise on the server. Ideas are welcome. 😀

Depending on your retry settings, that error might get retried and fetched on the client instead. This kind of achieves what you want, but in an ugly way (via errors).

So we pass the option to you. I’m throwing a ”Missing prefetch: …” error in the app I’m working on, this is something we should document.

The swr and RQ APIs are quite similar in this regard with the exception you mention @tom.sherman.is, if you forget to provide data for a query via HydrationBoundary/initialData, RQ will actually fetch, while swr will error.

You can still error in userland by configuring your fetcher to do so.

Agreed, and also, some advice is great for new projects but not worth the change and/or fragmentation cost in existing ones. I will also definitely be having this in mind next time I set up tests.

Just to be clear, they are still very, very common and there is nothing wrong with them, it’s just the stats I’m pushing back on, not the conclusion. 😀

I also have a problem with equalling SPA with client side only. Most SSR approaches are still SPAs in the sense they don’t do full page reloads, so it’s SSR+SPA. So I think that answer might include some noise like that.

State of React survey chart for application patterns

I think this is a misunderstanding. It’s from the State of React survey, (Usage->Application patterns) and it’s a multiple choice question.

”Which of the following architecture and rendering patterns have you used in the last year?”

SSR has 63%, SSG has 48%.

share.devographics.com/share/preren...

I still do not know unfortunately. The bane of conferences are that people who are usually online 24/7 suddenly go offline when they meet each other. 😅

I’ve been hanging at In The Wildeman, but will need to eat soon, happy to meet up!

I’m in the city! Send me where you ended up! 😀

I might join you! About to leave the hotel now, have you already left @acemarke.dev?

On my way to Amsterdam, looking forward to meeting so many friends, old and new!

👋 We're building a new type of word processor at Marker, and we're hiring for React/ProseMirror engineers and full-stack AI engineers to join the team in London.

Are you an engineer who cares about writing? Or do you know someone who does?

See: writewithmarker.com/jobs

More details below 👇

Guitar Chords in CSS In my previous article, I looked into the new, improved attr() method in CSS. I was over the moon...

*Very* cool use of typed attr() for grid placement! 😀

dev.to/madsstoumann...

Oh wow, I never thought I’d hear you say that, I’m happy you’ve made friends with them! I’m also happy I haven’t had to wrestle (much) with them myself. 😀

Oh yeah, for sure, and I agree, I just saw an opportunity to expand some of my thinking. 😀

If I say "this library has streaming support", which one am I talking about? Just `await fetch()` and passing the data down technically streams in Next.

I feel our language and terms hasn't quite caught up, I'd love better concise names/concepts to talk about these different kinds/things. 🤔

So in everyday communication I still think it can be hard to know exactly which kind of streaming a person is talking about. All of these needs different support in libs.

So I try to ask "What are you trying to achieve?" to get more context, so easy to be talking about slightly different things. 😀