
Show HN: React-Most – Declarative Monadic Reactive State Container for React - oyanglulu
https://github.com/reactive-react/react-most
======
mhink
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.

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

------
dawidloubser
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/](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?

~~~
mpfundstein
we totally do :-) believe me... its a constant point of frustration....

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

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

------
joshwa
Buzzword bingo!

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

~~~
MawNicker
There are distinct notions of monad. Just a note.

~~~
Nekorosu
That's not really helpful without at least two distinct notions of monads
shown.

