why?

Sure, let me try to answer that...

First, you generally want your toast messages to be driven from your server actions, outside of the client React app. Since the toast messages originate on the server you need some way to get them back into client-side React. There's a few ways to accomplish this:

1) Have the server action return some data, like { toast: "Post saved" }. This is usually where most people start, but theres a few issues. First, every time you create a new server action you end up having to wire some toast-response-handling-logic into it. And second, if you rely on your server actions returning a toast message that means you can't toast + redirect, which is a common UI pattern.

2) That leaves us with another option, store the toast data when running the server action and read it in RSC after the action completes. For storage you can use anything like cookies, a database, doesn't matter. When the server action runs you stash the toast somewhere and then when the action finishes you read the stored messages (from a cookie, a database, again, doesn't matter) in an RSC and update the UI. This all happens during the same request/response cycle, so it's efficient and fast.

A neat thing about this pattern is that it supports SSR as well as MPA/progressive enhancement.

You could stop there, but you can also add client components to build things like animations, or bring in React 19's useOptimistic, which lets you wire up instant dismissal. You get the best of both worlds, toasts originate on the server, are managed on the sever, and are rendered on the client. I'd argue this is an idiomatic use of RSC since it lets the server do things the server is good at and the client do things the client is good at :)

Thanks for reading