3 ms·
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 —
by 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 agoFair 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 agoYeah. 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).