First and foremost, I applaud the effort to encourage FRP in React applications, especially in the form of an actual library which treats it as a first-class citizen. I think this library is a step in the right direction for state management in Javascript. However, I <i>do</i> have a few thoughts.<p>When I first looked at this, I couldn't tell very clearly what advantages this library has over existing approaches to sequenced Redux actions, such as redux-loop or redux-saga, but I think I've got it now. The problem was that I've always thought of Redux actions as a "stream", so I wasn't clear on how this library was different.<p>It looks like you still have stores, but they're completely hidden in the HOC created when you `connect()` a React component to a stream (or a composition of streams) of intents.<p>I think this approach is interesting, and I really like the fact that the FRP mindset is "baked into" the library like that, but I don't think it makes a strong enough case for me, personally, to abandon the single-store approach.<p>On the other hand, I <i>do</i> believe that it sheds light on a Redux anti-pattern I've seen emerging: namely, the use of complex selectors which "reach into" the Redux store to pull out data in the appropriate shape required by a React component. In other words, Redux becomes a database, and selectors become queries.<p>The alternative (and better) approach, in my opinion, is very similar to how this library works. Where possible, create focused, denormalized reducers which store data in the closest possible representation to how it's intended to be consumed. By doing this, you can nearly eliminate the need for libraries like `reselect`.<p>At any rate, I'm rambling. In the end, I think the concept behind react-most is great, but I think its benefits are equally attainable in Redux, given good consideration and design.