Freelance developer - React Query maintainer - Occasional OSS contributor - Been putting React on servers for a decade - Father of two - Homebrewer

Stockholm
Fredrik Höglund retweeted
Our next major release is React 18. It will include out-of-the-box improvements like automatic batching, new APIs like startTransition, and a new streaming server renderer with built-in support for React.lazy. reactjs.org/blog/2021/06/08/…
84
1,290
4,390
Fredrik Höglund retweeted
Announcing Rome Tools Inc, an open source first company for @rometools rome.tools/blog/announcing-r…
83
320
1,900
Streaming Server Renderer running on the Edge, Server Components co-located with backend/databases.
2
3
Such a great chat! Great questions from @dulcedejae and @liuyenwei and very detailed and in depth answers from the team. Impressive to be able to talk about such a complex subject in an approachable way. Really looking forward to more of these deep dives, I learned a lot.
Replying to @reactjs
We’re kicking off the React Labs series with a Q&A on the React Server Components architecture! We invited @dulcedejae from FindMyPast and @liuyenwei from Pinterest for this conversation. Remember this video is a deep dive, and it’s not required watching. youtube.com/watch?v=jK0Vg8Xb…
2
10
This is super fascinating work to follow! Even if you don't want to deep dive into the code, just reading the PR descriptions gives you a very good high level overview of how it progresses and why.
2
A JavaScript lunch-chat in Swedish, starts in one hour!
I'm discussing “Javascript-snack mitt i lunchen” with @ephemjs, @ptz0n, and Frontend Sverige. Monday, 22 Mar at 12:00 PM CET on @joinclubhouse. Join us! joinclubhouse.com/event/PAgB…
1
1
I found a CFP I wrote in August 2019. The talk would explore doing dynamic streaming SSR "at the component level" and it would "end with a prediction about the future of rendering". I'm sad it wasn't accepted, but also that I can't remember what the prediction was. 🤔
8
Fredrik Höglund retweeted
Replying to @ephemjs
Was trying reading this and trying to get my head around it. I had no idea Trailers existed! Happy that they exist... but also sad that they don't support updating the things I *want* them to 😄
1
1
1
As I wrote in the comment, this can be avoided by frameworks or us developers preloading those chunks at the same time we start fetching the SC, but I think it's an underdiscussed part of the design.
SCs are nice because they run code and fetch data in the same request, and return the resulting tree. They also discover and stream which Client Components should be rendered, so we can start downloading them, but the SC needs to stream that back before they can start loading.
1
The code->data waterfall might not be obvious to all, so let me clarify. In the current case, unless you use something like Next.js get(ServerSide/Static)Props, you need to fetch and run the code for the next page before you can start fetching the data.
1
Server Components among other things wants to avoid a code->data waterfall. Out of the box you don't start fetching the client code before the SC returns, so are SCs creating a (much nicer) data->code waterfall instead? Wrote up some thoughts in the RFC: github.com/reactjs/rfcs/pull…
1
1
2
Upgrading to Webpack 5 today, any lessons learned I should be aware of besides the migration guide? Also, send me some good vibes and wish me luck. 😅 webpack.js.org/migrate/5/
1
1
Also, remember this isn't about Server Components, those are related but a separate thing. I think you could conceptually see SCs as a parallel asynchronous process going on that can resolve the various Suspense boundaries when they finish.
2
All the details of how and when everything is flushed etc is pretty involved and I definitely don't grasp it all yet, but starting from those two was helpful to me to begin building a basic high level understanding.
1
2
To understand the server perspective, I found it helpful to start from the central part we've all been waiting for, what happens when something suspends: github.com/facebook/react/pu…
1
2