Things I want to know about ReasonML

When I said "troubled about immutablejs/Redux/MobX choices for long", I'm talking about myself. I started learning React when Flux was just released in a conference. When I actually use Flux in our app, I realized I have to use immutablejs, and I did. Immutablejs turned out too heavy. After I got to know more people, I found immutablejs was hardly an option given that the bundle size is huge. I tried Redux for a while, not satisfied. Now I work in a team using MobX, there are troubles too although I have to admin MobX and MST is great idea.

It's not only me. I communicate with other Chinese React developers in WeChat for years. People found Redux does not appear natural. People asked about how about mobx-state-tree. People complained about immutablejs. Various kind of confusions.

I have been into ClojureScript for 2 years so far. It's much different air when people choose immutable data by default. I know it. I have some friends writing Haskell too, so I'm very familiar with Haskell, and not scared about OCaml. I'm quite confident that ReasonML would rid many confusions we have today like ClojureScript did to me.

However, ReasonML does not come with all solutions I need yet. In China there are lots of online shops, admin systems, and various kinds of sites built with React. And in my case, I'm working on medium-size(not sure about large yet) single page apps. Before betting on a new solution, I need to make sure those issues are solved:

• Immutable Data. It's simple enough to use persistent data in Clojure. I heard there are differences in immutable data between Clojure and OCaml since OCaml allow mutations in data. Will mutation bring problems in React?
• JSON string from Ajax. In dynamic languages, parsing JSON is trivial. ReasonML has types, would it become hard? Our apps interacts with server in restful APIs, lots of JSON strings are involved. I need to make sure ReasonML treats JSON gently.
• Nested Router. Already seen in recent releases though. Our app is using a router nested for several levels, nested router is a much have. Meanwhile we have to use router along with AntD menus/tabs.
• Global Store. Similar to Flux/Redux problems. We have global store, how does Reason abstract a global Store, as well as actions.
• Component States management. Already seen in component's reducer examples. Nice so far. Would like to investigate more complicated cases.
• Side effects in Components. Should be find since React has lifecycle hooks. But what's the differences in ReasonML.
• Type System solutions. We are using TypeScript. It's nice but personally I worried that type systems could become really complicated itself. ML languages use Algebra Data Types, which is unlike gradual types in TypeScript. Sometimes I'm wondering if I can really handle the tricky parts in ADT?
• Combine with React in js. Our app is large enough that we would never rewrite it totally in short time. As a result we have to accept ReasonML code exists as part of project, before we make final decision of refactoring.

As we try playing with ReasonML code, there will be more concerns in editor support and Webpack configurations. However that's not the largest problems for far.