ryantoron.to
43 posts
178 followers
24 following
Regular Contributor
Active Commenter
comment in response to
post
They are the worst :(
Also the AIs that start commenting on issues and other people's pull requests
comment in response to
post
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
comment in response to
post
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
comment in response to
post
Will do! Thanks for the nudge!
comment in response to
post
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)
comment in response to
post
Thanks Artem!
comment in response to
post
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?
comment in response to
post
Upstanding, trustworthy (the opposite of click bait, gossip)
I look forward to your newsletter every week, it's the best way to see what's happening in the React ecosystem
comment in response to
post
The Async UI Framework Checklist is great
comment in response to
post
this is fantastic. we've got a requirement in an app at work where we need to load all the images before rendering the next page. having all that done by react (and tied to a transition) is gonna be awesome
comment in response to
post
Wow that's awesome! Thanks for trying it out :)
comment in response to
post
RSC stream feels like it has so many use cases out outside of component rendering... it's like json on steroids.
comment in response to
post
Nice, thanks.
Additional transition is what allows the setState to get entangled/batched into the wrapping transition from the component?
Re-apply action context is nice wording.
comment in response to
post
Very cool, thank you. This helps and I love reading these threads.
If I'm making a component and I expose `saveAction={() => {...}`, is it fair say that it means:
1) Whatever callback you pass in here will be run inside of a transition
2) It can be sync or async
Any other rules I should follow?
comment in response to
post
Made some progress on this! Here's my test suite so far:
github.com/twofold-rsc/...
This is a little verbose, but I'm pretty proud of this attached test. It turns captured variables into function params.
comment in response to
post
This weekend I'm going to try implementing this. A plugin that turns a function defined in render into one that automatically encrypts/decrypts anything it closes over.
comment in response to
post
If you encrypt (or sign) those closed over variables before giving them to the client, then by the time they make it back to the server you know you can trust them. The server can skip auth/validation because if params decrypt they are 100% valid. It's like CSRF for every single hidden form input.
comment in response to
post
I've been thinking about this question a bit more over the weekend, it's a great one.
Is the main point of the question to highlight the unique thing about RSC is that it lets you decide where code runs?
comment in response to
post
Great list, thanks for that
comment in response to
post
What are the biggest limitations for you? What kinda stuff have you run into?
comment in response to
post
Ya, true. I love seeing all the frameworks experiment with their own versions of this. I still think it's worth having something like RSC built into React though. We're all writing backends to support client React apps and now we have a first class way to do it. That seems like a good thing?
comment in response to
post
Would be very cool. Gatsby had a useStaticQuery thing that would replace queries with data at build time. Always appreciated that, but a "use cache" would fun to explore.
comment in response to
post
To me RSC is a collection of features and ideas that shrink the gap between server and client. I think you need all the APIs in RSC to make that happen, and focusing on only a select few loses the forest through the trees. So not about smaller bundles, html, or serialization (for me at least)
comment in response to
post
Reason I like RSC is because it removes the boundary between server and client. You get server components that run sql and pass results into client components as props. And you get client components importing server functions that mutate your db. server/client gap is reduced to an import statement
comment in response to
post
Oh for sure, not new at all. I think it's interesting because it lets us avoid the server->client->server waterfall and also get the hoisting technique that we use w/ query+csr. It's an interesting way to tackle waterfalls, but ya not novel or unique to rsc (sorry wasnt trying to imply that)
comment in response to
post
Yup totally!
For the can't/shouldn't situations take a look at React.cache in RSC. It's short lived (only for the current render), but it allows you keep data fetching tied to a component while hoisting a preload/populate function to the parent.
Next example: nextjs.org/docs/app/bui...
comment in response to
post
To be fair the RSC crowd is doing a lot of work to avoid those server waterfalls. React's cache(), Next's fetch cache, and more recently "use cache" are all good attempts to help us avoid waterfalling on the server.
comment in response to
post
Missed opportunity for them to put their wildest puzzle ideas that never shipped into these advertisements.
comment in response to
post
Beautiful thing here is that you can go from step 1, to step 2, to step 3 without having to rearchitect your app. In each step you're just thinking about deriving UI from state.
comment in response to
post
Step 3: Layer useOptimistic on top of useActionState. Now you're back to being able to immediately update the UI without having to wait for the server, but you still get to sync action state between server and client.
comment in response to
post
Step 2: Add in server actions and useActionState. Now data lives on the server, but the UI is "slow". Actions queue and there's no UI update until the server responds.
comment in response to
post
Step 1: Start with client only state (useState/useReducer). It's fast and responsive, but data only lives client side.