Consolidate `switch%platform`, `browser_only` and `platform`

[jchavarri]

There's now a bit confusing situation:

• browser_only extension
• switch%platform which include Server and Client branches
• platform which includes js and native options
• server-reason-react.browser_ppx uses -js to discard stuff for (modes melange)

We could use React namings and semantics to make things easier for folks to understand.

Maybe we could do something like this?

• Remove platform as it's covering the same functionality as browser_only
• Rename browser_only to just client
• Add server to cover the platform native case
• Change switch%platform to switch%environment

So to summarize, we'd have:

• switch%environment with Server and Client branches
• let%client
• let%server

Wdyt?

---

Edited by @davesnx added server-reason-react.browser_ppx` example

[davesnx]

let%client and let%server can potentially collide with RSC ppx design thought. Personally, the _only suffix makes the intention clearer, so would rather keep let%client_only and server_only

[jchavarri]

let%client and let%server can potentially collide with RSC ppx design thought.

can you elaborate please? Edit: oh, i see, that we can use let%client as the OCaml version of use client and such. But it's not a conflict right? If you use use client then you only want to bundle that code only on the client which is what let%client would do.

Or in another way. Let's say we add let%client_only for this, and let%client for RSC. I guess people will ask "what's the difference between let%client_only and let%client and then we have to explain all implementation specific details, "this is Melange/OCaml boundary", "this is RSC server/client boundary" etc. I'd try to simplify as much as possible.

[davesnx]

We totally agree, but we might not add let%client for RSC.

If we can align both, it would be massive, but I'm afraid that isn't the case. Current browser_only discards functions and use client just changes react components.

We could make use client do all the work of browser_only (inside the module), but we can't remove browser_only since functions that aren't react components will also need it. The other interesting bit is that client components need the server implementation as well. which makes use client a bit to do.

[davesnx]

Worth sharing that there's a package called server-only that you import at the toplevel to enforce your bundler to not include those functions as server actions https://www.npmjs.com/package/server-only

And causes those kind of questions: https://www.reddit.com/r/nextjs/comments/18ih6nd/useserver_vs_serveronly/

[jchavarri]

we can't remove browser_only since functions that aren't react components will also need it

to clarify, i don't suggest to remove it but rather rename it so there's no different "concepts" going around (e.g. "browser", "client").

[davesnx]

I like this proposal a lot, I have been thinking about it and now that we implemented react.client.component and react.async.component` I have a new view on this:

I can replace js and native for client/server, I would keep the _only for clarity and verbosity and move the "platform" name into environment.

It would look like:

[@platform js] → [@client_only]
[@platform native] → [@server_only]
let%browser_only → let%client_only
switch%platform → switch%environment

This reduces the cognitive load of having to remember different names for the same things. Unifies [@platform js] and [@browser_only] into one. Removes the need of payload in "@platform".

Any thoughts @pedrobslisboa @jchavarri @andreypopp?

[GaborMatyas]

It would look like:

[@platform js] → [@client_only]
[@platform native] → [@server_only]
let%browser_only → let%client_only
switch%platform → switch%environment

I like this solution 👆👍

One Note: At first glance, the switch%environment name could be confusing if I were a newcomer and/or lacked context. My initial assumption would be that it refers to a staging vs. production distinction. Feel free to ignore this comment, as I don’t have a better name to suggest, perhaps switch%runtime_env, switch%runtime_target? Nah, these are not better either.

[andreypopp]

At first glance, the switch%environment name could be confusing

Agree, maybe something like switch%client_server?

[davesnx]

Most of the cases you would see this

switch%environment () {
  | Server => ...
  | Client => ...
}

so the confusion with env variables or prod/staging might be mitigated?

Anyway, good point. It seems like switch%platform might not be bad after all.

[lessp]

What about runtime? Also ambiguous?

[davesnx]

switch%runtime sounds good indeed

[davesnx]

I wonder if browser_ppx how should be called thought? Should be all bundled together with server-reason-react.melange_ppx or server-reason-react.ppx?

For now the philosophy was to keep the same structure as reason-react-ppx and melange.ppx

[pedrobslisboa]

Doesn't runtime have the feeling that it will be handled at runtime? The switch%{...} makes the "split" at compile time. After the compilation, there is no switch%{...} anymore:

let value =
  switch%platform () {
  | Server => doServerSideLogic()
  | Client => doClientSideLogic()
  };

// after:
let value = doClientSideLogic ()

I don't dislike switch%platform or switch%environment TBH.

Regarding naming, environment_ppx and platform_ppx seem to fit the idea if the philosophy @davesnx mentioned stays the same. While runtime_ppx also looks weird.