Show HN: React-Most – Declarative Monadic Reactive State Container for React

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 do have a few thoughts.

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.

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.

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.

On the other hand, I do 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.

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`.

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.

Really awesome little library. Nice work. I'm always excited to see different approaches for making react 'reactive'.

It's been interesting to watch so many ECMAScript / React libraries inch towards a Functional-reactive / streams-based paradigm. I can't wait to see which one becomes the de-facto standard, like how Redux is currently the de-facto implementation of the "flux" pattern in React applications.

Of course, https://cycle.js.org/ is one of the original attempts at a pure and simple implementation, and if you haven't studied it yet, it's wonderfully enriching to understand and play with - even if you don't end up using it in a project. (you may use Cycle.js with React, but it is agnostic of UI library)

As a software engineer in the third world, doing work mostly in the corporate space, I observe a near un-crossable chasm between the mindset required to understand and use Functional / Functional-Reactive platforms, and the mindset of your typical developer - doing .NET, Java EE or Spring. I fear it may be some time before we see adoption of libraries like these in the mainstream "day job" software world.

I don't mean to say that FRP is always "better" - but rather that it is beyond the comfort zone of typical corporate devs, despite the simplification its adoption may entail. Don't know if engineers outside of South Africa encounter the same problem?

Any advantage to just using Redux Observable and Rx (https://redux-observable.js.org)?

Looks neat and absolutely love the diagrams. Thanks for your work.

Buzzword bingo!

Can anyone explain what value does 'monadic' give to react?