[React Server Components] Idea to simplify overall design about rfcs HOT 11 CLOSED

The restriction that Client Components aren't allowed to import Server Components is the source of complexities.

Do you mean import or render?

from rfcs.

I think you may be conflating Server-Side Rendering (SSR) and Server Components. The former can render client components, the latter cannot. Either can import client components.

from rfcs.

@davidbarratt

Have look at https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#capabilities--constraints-of-server-and-client-components

Client Components [...] may not import Server Components

from rfcs.

@davidbarratt
Have look at https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md#capabilities--constraints-of-server-and-client-components

Oh right, I'm sorry I read what you wrote backwards. Yes the RFC makes sense to me. A client component couldn't import a server compoment because a server component could import Node's fs module (as an example). If that is the case, then how would you expect the client to handle that import?

from rfcs.

Let me elaborate with what I mean with:

• The webpack react plugin removes the server component source code from the client-side bundle.

Concretely the webpack react plugin would replace the entire source code of a Server Component with the client-side mechanism that calls the /_react/render endpoint. (More precisely with a call to that mechanism with as argument the ID of the Server Component.)

from rfcs.

Isn't that what shared components are? Basically the io libraries have both a server-side and client-side mechanism within them.

from rfcs.

@brillout Thanks for taking the time to share your thoughts. I’d like to reply, but we’d like to keep the discussion about Server Components focused in a single place. Could you please move this post to a comment on the main RFC? That way people can find the answer more easily wo following two separate threads. Thanks!

from rfcs.

@josephsavona done. I'm super looking forward to read your reply!

from rfcs.

@davidbarratt

A central piece of the proposal is

Once the virtual dom computing goes server-side it never goes back client-side.

For that, the server should be able to compute the virtual dom of all components, including the Client Components. The current design prohibits Client Components from running/rendering in the server.

Shared Components are not the solution either as they are prohabited to have state and side-effects.

from rfcs.

For that, the server should be able to compute the virtual dom of all components, including the Client Components. The current design prohibits Client Components from running/rendering in the server.

That is Server Side Rendering (SSR). If the client has already loaded the application, why would it need to render on the server? That wouldn't be effecient.

Shared Components are not the solution either as they are prohabited to have state and side-effects.

Right because you can't have state nor side-effects on the server...

from rfcs.

Responded in #188 (comment)

from rfcs.