Yes 100%

Do you have any recommendations for tooling? I noticed I'm getting way more strict about linting rules and even toying with bringing in some cyclomatic complexity and test coverage measures, but these feel like half baked solutions that are brittle (and annoying to others)

that router refresh demo is so good... especially when viewing the code and payload side-by-side.

just perfect for walking through how the server can refresh without losing client state.

this is incredible

i think you want a protocol from client->server so you can pass rich objects like promises, maps/sets, tmp references etc from c to s. fwiw under the hood rsc will use json when going from client->server if there are no rich objects, otherwise it uses FormData as a container for the flight payload

FlightServer.lean 👀 lets goooo!

Parallel and recursive route rendering RSC route rendering without waterfalls.

I added parallel and recursive route rendering to Twofold, which kind of blew my mind. It's the first time I've used a React pattern that specifically takes advantage of the two phase server/client render.

Wrote about it here: twofoldframework.com/blog/paralle...

thanks tom! i really need to give convex try, it looks awesome

thanks! i ran into a nasty bug a few weeks ago when our dashboard was displaying a bunch of "incorrect" information because queries were firing at different times

This post explores how components that read impure data can end up with inconsistent trees, and how React's cache function easily fixes that for you.

React Cache: It's about consistency Learn how React's cache function keeps your components predictable and consistent.

React Cache: It's about consistency

twofoldframework.com/blog/react-c...

it's awesome. my favorite piece about it is how it flattens all async calls and gives you the mental model of sync execution.

uAS+async will always run in order, and each call gets access to previous state even if it was called before the previous call finished 🤯

Process wise I write way more jsdoc comments now. I treat those as future proofing and guarding against any agent that comes into the code base.

Also I'm finding tests to be way more valuable these days. I look at tests as a cheap insurance option now.

I find it helpful it on the edges for non-app code. Like "make me a persistent hash map" that I can then tweak/play with.

Also it's amazing for autocompleting the current line.

But I'm not a fan of huge chunks of app code written with AI. I believe that requires taste that the agent doesn't have.

This switches to the react-server export condition for this import? I like it!

This can be hard to wrap your head around the first time you see RSC. I think it deserves a follow up post!

This is a great question. If you have <Intersection><RSC></Intersection>, the RSC will run on the server before <Intersection> runs on the client.

So you end up with <Intersection>Output from RSC</intersection>. You can wrap in Suspense to not block rendering, but it doesnt prevent RSC from running

Sounds interesting... Do you have an example UI in mind for that sort of use case?

Composable streaming with Suspense A look at two real-world UIs that rely on streaming with Suspense.

New blog post: Composable streaming with Suspense

One of my favorite patterns lately has been using Suspense to stream in lazily loaded content. It's perfect for dynamic dropdown menu options.

twofoldframework.com/blog/composa...

Great great article, thanks for sharing

I know it's a bit boilerplatey, but personally I've found the setState during render (increase/decrease example from docs) to work well with derived useStates based on changing props

Really enjoyed this one. Great post and the video walk through is fantastic as well.

They are the worst :(

Also the AIs that start commenting on issues and other people's pull requests

React Router RSC Preview React Router's preview support for React Server Components is now available

React Router RSC Preview is now available

This brings support for all of React's API in a way that is incrementally adoptable by the millions of React Router apps in production today, but also feels great for a greenfield React Router app

remix.run/blog/rsc-pre...

I'm willing to bet in most my RSC apps I'm passing larger objects than needed between server and client, but it hasn't really been a problem so far.

Agree with Jacob that it's about education. My 2c is devs need to understand .bind and serialization to do RSC well

I made this to help with hoisting and encryption for inline server functions github.com/twofold-rsc/...

Lemme know if you have any interest in something like that for Parcel

Server Components Give You Optionality | Daniel Saewitz

Server Components Give You Optionality saewitz.com/server-compo...

Will do! Thanks for the nudge!

It's so elegant, been using it for the last few weeks and I love it. Might be my favorite example of a directive because:

- Automatic cache keys
- Function hoisting similar to server functions (you can close over variables)
- Opaque references (passing children doesnt create a new entry)

Thanks Artem!

You can serialize a promise in React Use React to create a promise on the server and later finish it on the client.

New blog post on serializing promises in React. Learn how RSC serializes data between the server and client.

twofoldframework.com/blog/you-can...

Great post.

The squiggly line that splits the server and client components is an awesome UI and makes the code easy to read. Is that new?