ReasonReact - Reasons for current implementation approach?

reasonreact
#1

As a disclaimer: I didnt delve deeply into ReasonReact nor Reason since i’m still looking for a reason (pun intended) to switch from learning elm to learning reason, what intrigues me is the approach that ReasonReact is using when assimilating React into reason:

It is my impression that ReasonReact is trying way too hard to make creating ReasonReact components look like class components using a notation similar to objects or classes by creating a record/object using one of ReasonReact component functions and then spreading them into records/objects that we create.

Why this approach? React is, afaik, pushing to making functional components since they have more room for low level improvements than using class based components. Why cant ReactReason components be simple functions? I can make perfectly working solutions using only functional components in react and only using hooks and class components when trying to improve performance by manipulating the life cycle events.

Since reason primitives are (mostly) immutable a lot of these performance improvements that i did in javascript can be done under the hood by reason (pure functions, immutable data, etc) by pretty much the same way that Elm does. And Elm does use only functions (ignoring the fact that the language doesnt allow OO paradigms unlike reason).

My impression is that ReasonReact is only mapping functionality over to reason and not using reason (or any other ml lang) strengths.

Note: I like reason as a language and i think the similarity to javascript is a big plus in adoption rate, as well as reason’s flexibility in paradigms and even on allowing mutable constructs (to a lesser degree). I dont like ReasonReact though, it seems way too verbose and clunky for a perfectly functional language.

#2

It actually uses class based react component so it’s natural to make it looks like a class component. ReasonReact is 2 years old by the way, so all the fuzz about recent introductions of hooks is pretty new (not even in an official react release yet).

If you come from Elm, you shoud look for bucklescript-tea

#3

Why this approach?

The reason for this approach, as far as I understand it, is because ReasonReact are bindings for React. ReasonReact is not creating a new paradigm. If it was, I suppose it would be called ReactiveReason for something else entirely that was built on Reason and Ocaml core principles and patterns.

And as @thangngoc89 said, hooks is not even available yet in React, let alone ReasonReact. You probably want to wait a bit until those features land in react first.

#4

As others have said, ReasonReact is primarily shaped to be able to express normal React code. This allows it to benefit from the whole React ecosystem. In my opinion it is actually a very nice way to express the React idea of coding

But you seem to be more interested in ReasonReact as a GUI-building concept versus the Elm approach of composing pure functions and streams as a concept. So let me offer my perspective. While the Elm way is certainly interesting, I don’t think the science is settled that it is the superior way to functionally express GUI’s. Its complete disallowing of local state does have downsides. If you want functional GUI’s with local state components, you quickly end up with something like ReasonReact’s records, or something similar. Yes, it is more messy than Elm’s way, but also much more expressive.
As a third perspective, Reflex has much attention in the Haskell community. It too is a functional way to build interfaces allowing local state. But even with Haskell’s beautiful syntax, I personally don’t find it more clean to use than ReasonReact.

In conclusion I think you’ll find ReasonReact is a great and ergonomic way to build interfaces even ignoring the benefits of interfacing with React. And the added complexity of components versus Elm is justified by their much greater expressiveness.