[WIP] [DRAFT] RFC: React Module Conventions RFC v3

[Pranav-yadav]

[WIP] [DRAFT]

---

^{Originally posted by me; under related RFC v2 PR.}

Abstract:

In this RFC I propose minor yet effective changes to the React Module Conventions RFC v2. The term "client" is too generic both in Software/Web Development as well as in general. This type of extra generalism may lead to devastating effects on DX in various aspects. I propose; we should use "use csr" instead of "use client" to avoid confusion and generalism, by being explicit and not too generic.

Concerns:

1. "use client" : both experienced and newbie React Developer would be confused with the word "client", it's too generic, and on top of that, it sounds like we're using hooks. _{(feeling sorry for classes; no one mentions them these days 😎)}
   I get it, it's not that hard to get used to this but 👇 also, _{(see proposal after reading both of these concerns)}
2. This is going to be tough to digest for JS developers, at least for those still working with/seeing use strict, in their free time :).
   Since "use strict" is supported by the language itself out-of-the-box. Imitating the same syntax will confuse some JS devs and newbies that; "use client" is something that's also part of official JS ¹ (which could be devastating).
   _{(I get that some of us may be thinking only ɗŭmb devs will have this problem, but, hey, wasn't you also a newbie at some time?)}.
   Don't have hard suggestions on this but this confusion can be reduced by being explicit.

Proposal:

1. Using "use csr" : here we're being explicit. As almost every frontend/backend dev is familiar w/ what is CSR / csr, it's not that much confusing as compared to client

+ 'use csr';
- 'use client';
function doSomething() {
 // ...
}

2. Let's not use too generic term and confuse everyone instead let's use specific terms like SSR (ssr) and CSR (csr), that way we're trying to be explicit and the literal meaning is conveyed, leading to improved DX and flexibility.

3. Reserving "use ssr" for future use in SSR functionalities i.e. in the context of SSR.

4. Reserving "use ssg" for future use in SSG functionalities i.e. in the context of SSG.

5. Reserving "use isr" for future use in the context of ISR.

Glossary

• CSR / csr: Client Side Rendering
• SSR / ssr: Server Side Rendering
• SSG / ssg: Static Site Generation
• ISR / isr: Incremental Static Regeneration

References

Footnotes

1. NOTE
   The ExpressionStatements of a Directive Prologue are evaluated normally during evaluation of the containing production. Implementations may define implementation specific meanings for ExpressionStatements which are not a Use Strict Directive and which occur in a Directive Prologue. If an appropriate notification mechanism exists, an implementation should issue a warning if it encounters in a Directive Prologue an ExpressionStatement that is not a Use Strict Directive and which does not have a meaning defined by the implementation.

   --- TC39/ecma262

   ↩

[Pranav-yadav]

@sebmarkbage, @gaearon any initial comments/suggestions (about the concept, language, structure, etc.) on this RFC?
I would be happy to rewrite/update this RFC

[gaearon]

It's not right because this isn't quite what it does.

'use client' is not the same thing as CSR. It means you get both CSR and SSR/SSG/ISR (depending on your framework and other settings).

The correct way to think of 'use client' is not as a rendering mode. It's more like a split-point. It's where you cut off the server-only part of your code (which is the default at the module root and down) from the part of your code that needs to run on both server and the client (that's the one under 'use client' and anything imported from it).

This is still a bit confusing.

Another way you can think of it is that the only real "server" here is RSC. It's a true server in the sense that it has access to everything on the server. You could put it close to the database, and read directly. Now, your SSR is a client of that server. Your SSR could be on the edge — almost where the actual user (client) is. Your SSR's role is really to emulate what the client would do (and do it faster because you don't need to fetch code). That's why your SSR renders only the initial state of your client components. It's like a "snapshot" of the first frame that you can send very fast so the browser has something to show. This is why, conceptually, SSR is another "client" in our architecture.

Yes, this naming is confusing, but that's also because it adds a new piece to the architecture which slightly changes the roles of the other boxes on the diagram. I wish I knew a less confusing option, but this is not the one.

Thanks for writing this down.

[Pranav-yadav]

Thanks. I'll read more about the concepts (and the internals) and try to play with them in order to get thorough understanding.
Again, thanks for explaining it very clearly :)

PS: If it's possible please document your comments above in on react docs under advanced concepts/guides. Originally I looked at the docs there's not a single mention about it on react docs, (yet it's integral part of react, I know it's not required by day-to-day development). I did find good documentation related to this on Next's docs but after writing this raw-draft rfc, and didn't get time to complete it.