>Webpack and/or React must be very aware of what the other is doing here in order to drop the server-only JS from the bundle. Is it even possible to use alternate bundlers with this feature?
The bundler-specific code is here[1]. As you can see, it's not much. We will happily merge PRs and tweak the infrastructure to work with other bundlers. E.g. we're already in conversations with Parcel who are also interested. Yes, there is a cost in under-the-hood complexity, but we think you get a pretty high benefit (e.g. automatic code splitting), so we think it is worth that integration. Just like we take many other things bundlers do that we now take for granted.
>The React server has to be deeply concerned with the application logic to know how to transparently pass state back and forth, presumably via some generated JSON endpoints. I guess maybe this was already the case for hybrid client/server apps.
Not quite sure what you mean by this, but you be the judge: [2]. There is no "state" being passed. Server Components are completely stateless. (But they can render Client Components, which are normal React components on the client and have the lifecycle you're familiar with.)
>What's the lifetime of "persisted server-component state"? A component lifecycle? A page reload? A user session?
Server Components are not stateful. They follow a request-response model, just like traditional server pages. The novel part is that we're able to merge the result into the client tree (instead of .innerHTML = newHTML with old school partial templates, which destroys client state).
>How did they make an asynchronous call synchronous? JS doesn't normally allow that outside of an async/await context. Did they wrap the JSON response object in some kind of lazy proxy or something?
We will be posting a separate RFC in the coming weeks/months that dives into details. But the high-level answer is that we want to model it as a cache that you read synchronously. (So if the answer isn't synchronously available, we throw and retry later.) Async/await adds unnecessary overhead when content is already available synchronously, and especially on the server we'll expect many synchronous cache hits because some data has already been accessed from a parent component. Think of DataLoader-like abstractions.
I may have misunderstood. Here's what I was referring to:
> Server Components preserve client state when reloaded. This means that client state, focus, and even ongoing animations aren’t disrupted or reset when a Server Component tree is refetched.
As well as the part in the video where non-serializable props are referred to, in the context of implicitly sending data between client and server (these may in fact be two separate topics).
But either way, surely the quoted paragraph requires some highly-magical behavior?
Here's one way to think about it. Imagine a traditional webpage. It renders to HTML. If you refetch it, you get new HTML. You can't simply "merge" two HTMLs on top of each other, so if you were to "update" document.body.innerHTML to the new result, you'd blow away focus, selection, etc.
Now imagine the server sent "virtual DOM" in the response instead. React knows how to "merge" such updates into the tree without destroying it. This is what React has been doing all along, right? So this is why we can refetch the Server tree, and show the result without blowing away the Client state inside.
Now, this virtual DOM tree contains things like divs (with their props) or references to Client Components (e.g. "module number 5 in bundle called chunk3.js") with their props. These are the things that need to be serializable. But they're only passed from Server to Client, not back. Think of them as the same role as HTML attributes.
The bundler-specific code is here[1]. As you can see, it's not much. We will happily merge PRs and tweak the infrastructure to work with other bundlers. E.g. we're already in conversations with Parcel who are also interested. Yes, there is a cost in under-the-hood complexity, but we think you get a pretty high benefit (e.g. automatic code splitting), so we think it is worth that integration. Just like we take many other things bundlers do that we now take for granted.
>The React server has to be deeply concerned with the application logic to know how to transparently pass state back and forth, presumably via some generated JSON endpoints. I guess maybe this was already the case for hybrid client/server apps.
Not quite sure what you mean by this, but you be the judge: [2]. There is no "state" being passed. Server Components are completely stateless. (But they can render Client Components, which are normal React components on the client and have the lifecycle you're familiar with.)
>What's the lifetime of "persisted server-component state"? A component lifecycle? A page reload? A user session?
Server Components are not stateful. They follow a request-response model, just like traditional server pages. The novel part is that we're able to merge the result into the client tree (instead of .innerHTML = newHTML with old school partial templates, which destroys client state).
>How did they make an asynchronous call synchronous? JS doesn't normally allow that outside of an async/await context. Did they wrap the JSON response object in some kind of lazy proxy or something?
We will be posting a separate RFC in the coming weeks/months that dives into details. But the high-level answer is that we want to model it as a cache that you read synchronously. (So if the answer isn't synchronously available, we throw and retry later.) Async/await adds unnecessary overhead when content is already available synchronously, and especially on the server we'll expect many synchronous cache hits because some data has already been accessed from a parent component. Think of DataLoader-like abstractions.
[1]: https://github.com/facebook/react/blob/6cbb9394d1474e3a728b4...
[2]: https://github.com/reactjs/server-components-demo/blob/a8d5c...