This is huge, and I think it could have implications beyond the ecommerce store. I know it relies heavily on React Server Components, is part of the long tail on this due to the fact that those haven't shipped in stable yet?
Correct, we're shipping with an initial version of React Server Components (RSC) that works in Vite and uses file suffixes. Hydrogen provides missing pieces to the current version of RSC, like data fetching and other dev tooling.
We're working to align with Vercel on improving the conventions of server modules (e.g. dropping the filename suffix): https://github.com/reactjs/rfcs/pull/189#issuecomment-111648... and we anticipate to release future versions of Hydrogen and Next.js that use something like boundary annotations instead.
To say this though, I prefer the file extensions bit, e.g. `.client.ts` and `.server.ts` over directives. Directives aren't super discoverable at a glance, and I think will lend themselves to a lot more headache in terms of engineering practice.
I realize its better for compilers probably, but it hinders DX for large applications IMO.
Initially we'd proposed just dropping `.client.` and keeping `.server.`. This area overall is still being worked out, and the two options aren't necessarily mutually exclusive.
That's good feedback. The directive approach relies much less on initial discoverability and tedious work which enables it, like naming each and every JS module a certain way up front. Instead, it relies on error handling and developer response/correction. I'm definitely curious to see whether that tradeoff is worthwhile.
I know Typescript now has a `moduleSuffixes`[0] option that may be be a reference point for making this easier. I am imagining you want to do this due to compiler conditions for build tooling no?
This makes it "transparent" to the developer but retains the file naming approach, best of both worlds?
