4 ms·

Only reason why I would use RSC's over Astro is to share context between islands. There's no other major benefit. Also, nit, but I wish this article explicitly

Only reason why I would use RSC's over Astro is to share context between islands. There's no other major benefit. Also, nit, but I wish this article explicitly mentioned and explained Astro's "code fence" idea. It's demarcates the boundary between server and client much more clearly than React's 'use client'.

pier25 1y ago
> share context between islands This is extremely easy to solve with Astro: https://docs.astro.build/en/recipes/sharing-state-islands/ https://docs.astro.build/en/recipes/sharing-state-islands/
- skeptrune 1y ago
  >In Astro, you can nest Astro Components inside Client Islands, but if those include more Client Islands, they’ll still be seen as separate roots by your framework (e.g. React). This is why nesting interactive behavior doesn’t compose as naturally as in client apps, e.g. React or Vue context can’t be passed between Astro islands. I agree with what the link author wrote here. Nanostores is great (s/o EvilMartians), but it's not as natural or easy to use as each respective framework's context solution.
  - pier25 1y ago
    You're right. Sorry I misunderstood. For some reason instead of "context" I read "state".
danabramov 1y ago
I slightly disagree with your nit. I don’t think code fence really demarcates the boundary because the code below the fence definitely does run on the server — otherwise, referencing other Astro components wouldn’t work there. The fence represents the “bindings vs template” separation but not “server vs client” in my reading.
- skeptrune 1y ago
  Fair point, you've convinced me on the "bindings vs template" distinction. However, from a developer's perspective, the ability to securely make backend requests with secrets in the top fenced area and pass results to the template still feels like a clear "server-side execution context" boundary.
  - danabramov 1y ago
    Yeah. Not saying it’s the same thing but the conceptual equivalent to this boundary is import "server-only" This causes a build error if imported from a client environment. So the intended usage is that you put that into your secrets (and maybe even in your data layer entry point) and you’re golden. It will poison any transitive import that eventually imports that thing. The developer wouldn’t necessarily “see” where they are at any given moment but importing the “wrong thing” would give them a module stack trace so they can decide where to “make the cut”. It takes a bit to embrace this workflow but it’s productive once you “mark” what’s server-only. The enforcement of “can’t use state on the client” is built on the same mechanism but inverse (client-only).

pier25 1y ago

> share context between islands This is extremely easy to solve with Astro: https://docs.astro.build/en/recipes/sharing-state-islands/ https://docs.astro.build/en/recipes/sharing-state-islands/

skeptrune 1y ago
>In Astro, you can nest Astro Components inside Client Islands, but if those include more Client Islands, they’ll still be seen as separate roots by your framework (e.g. React). This is why nesting interactive behavior doesn’t compose as naturally as in client apps, e.g. React or Vue context can’t be passed between Astro islands. I agree with what the link author wrote here. Nanostores is great (s/o EvilMartians), but it's not as natural or easy to use as each respective framework's context solution.
- pier25 1y ago
  You're right. Sorry I misunderstood. For some reason instead of "context" I read "state".

danabramov 1y ago

I slightly disagree with your nit. I don’t think code fence really demarcates the boundary because the code below the fence definitely does run on the server — otherwise, referencing other Astro components wouldn’t work there. The fence represents the “bindings vs template” separation but not “server vs client” in my reading.

skeptrune 1y ago
Fair point, you've convinced me on the "bindings vs template" distinction. However, from a developer's perspective, the ability to securely make backend requests with secrets in the top fenced area and pass results to the template still feels like a clear "server-side execution context" boundary.
- danabramov 1y ago
  Yeah. Not saying it’s the same thing but the conceptual equivalent to this boundary is import "server-only" This causes a build error if imported from a client environment. So the intended usage is that you put that into your secrets (and maybe even in your data layer entry point) and you’re golden. It will poison any transitive import that eventually imports that thing. The developer wouldn’t necessarily “see” where they are at any given moment but importing the “wrong thing” would give them a module stack trace so they can decide where to “make the cut”. It takes a bit to embrace this workflow but it’s productive once you “mark” what’s server-only. The enforcement of “can’t use state on the client” is built on the same mechanism but inverse (client-only).