What's the best way to handle global state in ReasonReact?

reasonreact
#21

Am I wrong thinking that all these approaches suffer from the issue that, when any state branch updates, every component that is subscribed to the state gets updated? And not exclusively components subscribed to the updated branch? My current react-js app suffers from this right know, and I am wondering how a ReasonReact port might solve the issue.

#22

Haven’t tried the but I reckon the combination of immutable structures and structural sharing would make that fairly easy to handle? Fwiw statext handles that fairly well (in js React) and it should only be easier to do in Reason.

#23

Hi Ostera,

I’ve just posted questions on:
Discord > ReasonML > #react

…about how to separate application logic from ReasonReact, inspired by CycleJS’
main() > isolated side effects (vDOM).

Here is a snippet:
"I think there is a lot of merit to the way CycleJS is looking at app design and I’m hoping to take aspects of it and incorporate it into a real functional language like Reason as I learn to program. And with a pattern like Callbags it should be possible to implement declarative, funcitonal, reactive programming.

I guess what I’m really asking is are there any established approaches in ReasonReact that:

  1. keeps imperative programming to the absolute minimum?
  2. keeps side effects isolated from the main app logic?
  3. manages all application state, except for occassional state not shared by UI components, in an immutable singular store (like Redux or Onionify)?
  4. allow us to stream data into components rather than calling “state” properties and methods in an OO style as is often done in ReactJS?"

How can we define a model for separate application logic/framework that can become a first-class citizen in the ReasonML community, alongside the standard React way? One where we use elegant patterns rather than opaque libraries and APIs?

Why is the traditional method, of sprinkling application framework throughout React, still something that is embraced by the functional ReasonML community? Feels like a contradiction of why we are using a functional paradigm.

Should I go with Reason for my next production app?