I'm always confused by statements like "You don't need Redux, you have reducer components".
Reducer components don't solve the problem of a centralized/shared/common state and interactions between components.
Reducer components don't solve the problem of a centralized/shared/common state and interactions between components.
We've been converting a large JS react app to Reason, and strongly typed props solves a lot of problems. Passing props down multiple children is no longer a burden, and you'll never have that "prop spreading madness". For anything that reaaally requires some sort of global state, you can use the new react context api.
The only danger of writing in reasonml is spoiling javascript for yourself
Curing yourself :)
Is the process like say converting to using Flow where you can just add it in where you want and the application still runs fine, or by convert do you mean write a whole new application and when it's complete then launch?
1. A pattern to organize their state in that was testable and repeatable
2. A way to maintain global app state without prop drilling
I think that (1) is actually the reason that many people pick Redux in the first place. The amount of global, app-wide state in /most/ applications is fairly small IME. I think that the ReasonML team (which works semi-closely with the React team) is banking on things like Apollo, "suspense", the new context API and other things to further reduce the need for a global state store like Redux.
The ReasonReact devs are trying to follow the principal of least power in providing something that solves (1) for component-level state, which solves the 80%, and wait for the rest of the ecosystem to shake out for the rest.