Some might have noticed that there is already a @rescript/react package, which is a simple ReScript syntax port of reason-react with a few renamed module names (and very old apis removed). We didn’t do much advertisement around it just yet, because we are still doing some fine-tuning for edge-cases where existing reason-react users experience problems in their migration (it involves some simple breaking changes).
There is one particular migration issue that is more related to package management than actual apis: If your app uses another ReScript package that depends on reason-react, you can’t really mix it with @rescript/react code, because both packages occupy the React module in the global scope, which will confuse the compiler. More details can be found in this recent issue.
From our POV we thought it wouldn’t be such a big deal, because the migration from reason-react -> @rescript/react was just a matter of changing the npm dependency and globally regex-replace a few names (ReasonReact -> RescriptReact). But I can understand that this might be an actual deal breaker for some folks in certain circumstances or setups. Right now we are still able to fix things up.
It would be interesting to know how many early adopters had problems so far using @rescript/react (due to breaking 3rd party deps), or have any other kind of feedback from their side.
If your app still runs on reason-react, maybe let us know what third party libs you are using that have a dependency to reason-react as well to get a bigger picture.
To be clear: We don’t expect / force every user to migrate right away. We just want to make sure everyone has a pretty easy upgrading experience later on. Move at your own pace and continue working on your products while we figure out the details.
As soon as we have a clearer picture on common issues we will document everything properly.
Last Note:
If you are already using @rescript/react and it works: Great!
Hi,
for big project, I like to use CSS-IN-JS styled-component library, and styled-ppx the closest solution I found (styling is for me the BIG sticking point of react with rescript/reason)
I planning to refactor another project that use Relay, and I think reason-relay will prevent me using @rescript/react
ReasonRelay will move to use @rescript/react in the near future, and will eventually be renamed to ReScriptRelay + fully embrace ReScript. You can read more about that work in this issue: https://github.com/zth/reason-relay/issues/148
Speaking of - @ryyppy when are the docs due for release? Or are they already released perhaps and I’ve missed it? I don’t think I want to move to @rescript/react until there are docs available.
The docs were silently released (as mentioned by @gargakshit).
I’d still like to add some more content before I want to properly announce it, because a few hooks, proper interop docs, etc are missing, but generally I’d say the docs are pretty nice.
bs-react-helmet hasn’t been changed for 17 months now, and bs-react-intl didn’t change for 9 months. Please, do yourself a favour, and copy these two files e.g. in some src/bindings folder and completely remove your deps from your project (but add the actual js dependency react-helmet / react-intl). Copying a 50 line and 500 line file is fine (please believe me in that regard). You can also easily transform those copied files to ReScript syntax as described in our docs.
When these projects ever decide to publish a new @rescript/react equivalent, you might be able to switch back using npm dependencies, but honestly, I think you will keep the local files because it’s just so much easier to maintain (like applying quickfixes).
I upgraded npm before upgrading rescript/react and it caused chaos on all the peer dependencies not just in rescript/react but in other libs as well. I had to use the flag to disable this behavior.
I get the impression that the long term direction is to figure more ways to automate generating custom bindings and reduce the need for these npm packages altogether?
reason-apollo-hooks was deprecated for rescript-apollo-client because the upgrade to Apollo 3.0 and upgrade to graphql-ppx 1.0 almost required a full rewrite. To not have huge breaking changes, it was released under a new name. It’s alive and kicking!
Writing bindings to a GraphQL client is quite elaborate to do well, and writing your own bindings is probably a huge time sink (check the code size of rescript-apollo-client). For smaller libraries I agree!
