It depends a lot on what you’re using it for. If it’s a 0-runtime binding to existing react-dom code then it can still be found in ReactDOM, so it’ll be a simple rename. If it’s for aria- or data- support then you can move to JSX. If you (or anyone) is concerned about their specific situation, please give details about the situation! If you don’t feel comfortable posting here, reach out to me on Discord/Twitter.
1 Like
Well, the majority of the usages are Style, Ref and renderToElementWithId. AFAICS, only the latter is non-zero-cost. Will helpers like this be deprecated?
Anyway, I don’t think it’s gonna be a big deal for us: we can copy the helper and then it’s a simple rename as well.
1 Like
Thanks for the answers. I understand the performance implications (but it’s a trade-off as well, is it really worth the integration for a 10% performance win?). I also hope there would be a way to do something like this in the future without ppx-es that doesn’t have this trade-off (better implementation of ppx’es or macros?). But that is not relevant to this discussion.
An alternative idea is to configure it as if it’s a ppx, but reason-react is special cased (it looks at the version - or hash of the ppx binary - of reason-react, and then calls the vendored ppx directly). This also allows you to run an experimental version of the reason-react ppx while not needing a patched ReScript.
This would simplify configuration (we don’t need to have a special jsx configuration, but we just have to include the ppx)
I am currently working on a native UI, that works both on web and native. It would be nice to be able to drop it into an existing React application (but it might need two JSX transforms in the same app). So if react-jsx would behave more like a ppx, and ppx’es are configurable on a per-folder basis, it would allow these experiments/innovations. Aside from that I can also see a use-case for using JSX for other things, not necessarily UI (see for instance pastel for the command line) in an application where React is also used.
It’s also a way to make sure that everyone is using the same implementation of JSX, without much configuration and extras to install. Goal is to have a simple one-stop installation that just works, and is fully tested with the whole system (compiler, syntax, error reporting, editor-support).
react-ppx is not enabled by default, so you can write your own ppx and hook it up like any other. There is no special compiler support needed for that to work, so you could just fork the react-ppx code and build a custom ppx instead.
We don’t really want to experiment too much around with different jsx ppxes (the less options, the better), so hopefully the jsx v4 change will be stable for quite a while.
2 Likes
Reviving this one - any updates for v1.0?
Also wondering about React 18 support, is that something you’ve had a chance to have a look at? It’s mostly about binding to the new concurrent mode APIs etc, I think.
There are currently some open questions on how to proceed with the new react-ppx. Maybe there will be some fine-tunings in the compiler that will allow us to get rid of the makeProps interface. Will take some more time until we know how to proceed. v1.0 is kinda dependent on that.
Didn’t have the time to look at it (still a lot of code based on v15 / v16). According to the announcements I didn’t see many blockers that prevent users to write quick bindings to those apis?. Are there many ppl / libraries using React v18 successfully already?
Ahh, I see. Thank you for the update.
Yes, writing your own bindings is possible, so it’s no blocker. But it’d be nice to be able to leverage the official ones instead. This might be “local” to rescript-relay, where both internal APIs in the lib + external use of the lib has been concurrent mode compatible for a long time now. I’ve shipped a ReactExperimental binding for the concurrent mode API:s, but it’d be nice to finally get rid of that and move to official bindings now that the concurrent mode features are stable enough to be included in the main React package 
I didn’t have the chance to use concurrent mode yet since our codebase is still based on v15 and v16. If you are running your own v18 API bindings in production already, we can start a discussion on the rescript-react repo and start thinking of including it upstream?
We’d also need to think about concrete documentation on the topic, with proper examples etc.
Sure, let me open an issue for discussion on the repo when I get a chance.