I've been digging into React Server Components via @ShopifyDevs Hydrogen, and I'm very impressed & excited
Here is a visual explanation of my understanding of RSC and what it means for you 🧵:
First, how do you author server components?
In short, they are just React components! With all the latest goodies of concurrent mode, such as elegantly fetching data via hooks
Server components can even fetch private data and are denoted by a file ending in *.server.js
Next, how do you load these components?
For Hydrogen, the top level is always a server component.
But, with some caveats, you can mix server components, client (aka traditional) components, and shared components (components that can render on server OR client), in one tree
So, how do pages load?
Because of the benefits of concurrent mode, like suspense, we can load pages via streams
For instance, with my Hydrogen app, the header loads immediately as HTML, and then the body (which has dynamic data) streams in each piece as it is ready
For the nerds: I find the streaming format very interesting
It is a mix of metadata and VDOM JSON.
It is separated by newlines so each line can be processed at a time, not having to wait for the final result to parse the body
It is fetched as /react?state={pathname:'/', ...}
Then, the coolest part. Client-side routing is done without a refresh and doesn't require any new JS to load
The client fetches the new VDOM from the server, which may process lots of JS that doesn't need to load in browser
As it streams in, React patches in the minimal changes
The result is a pretty great experience. With some caveats about new mental overhead in needing to have some concern about where is the best place to put certain data and logic (client/sever/shared), you have a very new, very performant way to build fast + dynamic React apps
Why have we been diving in? We've been integrating @builderio to Hydrogen and having a blast. It's a great new set of tools to build with for your whole team
And I invite anyone from the @ShopifyDevs or @reactjs team to correct me if I got anything wrong, I am still digging in to form my understanding and excited for more docs + examples to come
• • •
Missing some Tweet in this thread? You can try to
force a refresh
LLMs are bad at acknowledging what they don't know
But they are good at answering questions from a well defined context
So instead, you can provide a set of information via RAG (retrieve it and supply it in the prompt) and tell the LLM to *only* answer questions from this data
Don't be that teammate who blindly refactors code and only makes things worse.
Let's look at some good vs bad refactoring patterns with real examples 🧵
Let's take this code.
I hired a developer once that saw us calling this `functions.runWith(...)` repeatedly with different options and decided to consolidate it all into one createApi function
This new, consolidated code, had a huge issue.
Can you see it?
When we started deploying these APIs, they began breaking left and right.
In all seriousness though, I know I post a lot of coding tips and "do this not that" best practices stuff, but I want to use this as a reminder to point out...
I don't write perfect code. No one does. My code has been complained about by fellow engineers as much as anyone, if not probably more.