5 ms·

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

47 points by oyanglulu 10y ago

griffinmichl 10y ago
Really awesome little library. Nice work. I'm always excited to see different approaches for making react 'reactive'.
polskibus 10y ago
Can anyone explain what value does 'monadic' give to react?
- MawNicker 10y ago
  There are distinct notions of monad. Just a note.
  - acedinlowball 10y ago
    Is that so? Just a note.
  - Nekorosu 10y ago
    That's not really helpful without at least two distinct notions of monads shown.
  - mpfundstein 10y ago
    a data class / object is a monad if it confirms to the 3 monadic laws [1]: Left identity, Right identity and Associativity. To do this, it must implement two functions. 1. chain (also called 'flatMap', '>>=' in haskell). 2. unit (sometimes called 'of', for instance in js). Nothing more is needed to understand and implement a monad in any language. [1] https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws
- oyanglulu 10y ago
  that you can simply flapmap async transform of state to sink
imjared 10y ago
Looks neat and absolutely love the diagrams. Thanks for your work.
mhink 10y ago
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.
ctvo 10y ago
Any advantage to just using Redux Observable and Rx (https://redux-observable.js.org https://redux-observable.js.org)?
joshwa 10y ago
Buzzword bingo!
dawidloubser 10y ago
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 10y ago
  we totally do :-) believe me... its a constant point of frustration....

47 points by oyanglulu 10y ago

griffinmichl 10y ago

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

polskibus 10y ago

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

MawNicker 10y ago
There are distinct notions of monad. Just a note.
- acedinlowball 10y ago
  Is that so? Just a note.
- Nekorosu 10y ago
  That's not really helpful without at least two distinct notions of monads shown.
- mpfundstein 10y ago
  a data class / object is a monad if it confirms to the 3 monadic laws [1]: Left identity, Right identity and Associativity. To do this, it must implement two functions. 1. chain (also called 'flatMap', '>>=' in haskell). 2. unit (sometimes called 'of', for instance in js). Nothing more is needed to understand and implement a monad in any language. [1] https://wiki.haskell.org/Monad_laws https://wiki.haskell.org/Monad_laws
oyanglulu 10y ago
that you can simply flapmap async transform of state to sink

imjared 10y ago

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

mhink 10y ago

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.

ctvo 10y ago

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

joshwa 10y ago

Buzzword bingo!

dawidloubser 10y ago

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 10y ago
we totally do :-) believe me... its a constant point of frustration....