Sam Selikoff

Awesome. I think a <Button pressAction={}> component from Aria would be a killer example to motivate this pattern!

Maybe I can work on this next after we get Activity merged

Building Reusable Components with React 19 Actions | Aurora Scharff In this blog post, we will explore how to build reusable components with React 19 Actions, track transition states, use optimistic updates, and expose action properties for custom logic.

Here's another example from from @aurorascharff.no:

aurorascharff.no/posts/buildi...

She actually follows exactly the pattern Seb mentioned in that github thread with Devon

Spinner – Radix Themes Displays an animated loading indicator.

I actually do think this use case is realistic if you use the absolute positioning pattern like here: www.radix-ui.com/themes/docs/...

I have a <Spinner> I copy-paste around all my apps that does this. A <Button clickAction={}> that did this would be great for design systems to have.

a server action but the UI could flip immediately. It would also flip back if the action failed.

I think that's a good use case!

I've been wanting to help here recently. At ReactConf last year Andrew suggested libs like Radix should start accepting action* props in addition to on* event handlers.

Example would be

<Switch changeAction={updatePreference}>

If the transition/optimistic was baked in, you could pass in

He said that even if AI books became good, he still wouldn't be interested in them, because there are so many authors he still hasn't read yet. Found myself nodding along with his take.

Neal Stephenson said something similar recently about writing. Can't find it right now but he basically said, people read books because at some level they know a person wrote them, and that person wrote it for a reason.

Giving the docs for the awesome experimental <Activity> component a once-over this morning 💅

Method missing in ruby is unhinged/awesome. But can also create nightmares haha

Ah right I was mis-remembering inline 'use server' in <form action={}> being an rsc.

I am curious to see how the modules declarations proposal plays out. It'd be nice for the teaching story to avoid making a separate file, because the motivation for that is usually organization, not functionality.

🤔

This should be the hello world of RSC!

Great point 👍 I guess the point isn't about syntax vs runtime, but that introducing an async function requires the whole chain to add `.then()`. That's the contamination. Seems different from hooks, which for example don't force an existing component to be rewritten.

Components are functions that call hooks but themselves don't become hooks. But I get your point – however I still think it's different because the rules of hooks are about runtime behavior within React. Async functions contaminate the chain of code at the syntax level.

100% agree. The warning has been the best way to teach it

I'd love if this were blessed, last time I spoke with Andrew/Seb they said they were working on some new APIs/primitives for it. But to me SA fits so nicely here.

One of my all-time fave React talks ✨

If I were writing about this I would 100% focus on all of the intermediate states that are eliminated from the frontend's concerns as a result.

Definitely! But since it’s a library it’s not as deeply integrated into the tooling. What I’m thinking is something like: a server action gets the type checked like normal at the calling site, but the args are “unknown” in the implementation.

Yep zod is great but I'm more asking from the perspective of integrating the tooling (a la the meat of your post). Just like the compiler can tell you if you are passing in a non-serializable value to a client component, I wonder if it could tell you if the argument is untrusted.

a reminder for the SA implementation. Curious if you have any thoughts here!

opening the network tab and replaying the action sending over a number instead. So I've been doing something like

export async function likePost(unsafePostId: string) {
if (typeof unsafePostId !== 'string') throw;
const postId = unsafePostId;
// ...
}

so I get type safety for the caller but

Any thoughts on how the type system could surface security issues wrt to server action args?

If I understand correctly, typing args – e.g.

"use server"
export async function likePost(postId: string) { ... }

is awesome for ensuring correct usage in the codebase, but it doesn't stop someone from

Also feel like there's nowhere to go for deeper technical discussions these days. It's a huge bummer.

I loved it. Feels like it could generalize to trees too

"Stores want normalized data, but screens want graphs"

Loved this phrasing from this instantdb essay. Lots of overlap regardless if you're local-firsting or not: www.instantdb.com/essays/next_...

Ooh that's a great one 👌

Contrived but very easy to connect to real-world situations. Markov tolstoy less so haha

The input/graph/clock from your transitions talk was so good, where did that one come from?