Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MobX – Simple, scalable state management for React

mobxjs.github.io

Post reply on HN
Print view View original

11–20 of 27 posts

Re: MobX – Simple, scalable state management for React

#11

Post by nightski »

rpedela wrote: post #9
mweststrate wrote: post #5

Earlier quoted context omitted.

The idea is very much like knockout and meteor, but the reactivity implementation is completely different. First all it is generic and not designed for just the UI. MobX is completely glitch free and synchronous and has explicit distinction between computed values and reactions (side effects like updating the DOM). More important, MobX determines the right execution other of derivations on the fly, preventing issues…

> MobX is completely glitch free MobX looks interesting but I am a little concerned that you are claiming it is bug-free.

I don't believe he meant glitch in the sense of bugs but rather in FRP terms. I.e. temporarily inconsistent state.

Re: MobX – Simple, scalable state management for React

#12

Post by Klathmon »

diggan wrote: post #10
megalomanu wrote: post #6

Mobx is a blessing ! I work on React only since a few months, I have a ton of subjects to learn, a ton of libraries to learn to how to use them. I really don't have time to learn a complex library like Redux. I tried, and learned its principles, but I soon saw that it would totally transform my existent codebase into a large cream cake with some boilerplate code everywhere. I come from Java world, which is often mock…

I haven't used Moxb but I've used Redux a lot the last 6 months, building mobile apps and also a rewrite of our frontend at Typeform. I'm not sure how Redux could be considered complex, the API is very small and the ideas are small as well. There is really not much to learn with Redux. Redux is like literally 100 lines of code if you remove comments and simple sanity checks. Also, not sure what you mean with boilerpl…

Personally I found that using redux for everything ends up spreading a ton of boilerplate everywhere. Action creators, reducer, the dumb component itself, the HOC.

All that adds up and is a lot of work for a simple component.

We ended up going with a hybrid setup. Our components are all dumb, and our "pages" are the only connected components. We also started using ducks[1] instead of spreading the reducer/actions everywhere whenever it makes sense.

[1] https://github.com/erikras/ducks-modular-redux

Re: MobX – Simple, scalable state management for React

#13

Post by tptacek »

diggan wrote: post #10
megalomanu wrote: post #6

Mobx is a blessing ! I work on React only since a few months, I have a ton of subjects to learn, a ton of libraries to learn to how to use them. I really don't have time to learn a complex library like Redux. I tried, and learned its principles, but I soon saw that it would totally transform my existent codebase into a large cream cake with some boilerplate code everywhere. I come from Java world, which is often mock…

I haven't used Moxb but I've used Redux a lot the last 6 months, building mobile apps and also a rewrite of our frontend at Typeform. I'm not sure how Redux could be considered complex, the API is very small and the ideas are small as well. There is really not much to learn with Redux. Redux is like literally 100 lines of code if you remove comments and simple sanity checks. Also, not sure what you mean with boilerpl…

Redux isn't conceptually complex, but I found it hard to get started with. The trouble I had wasn't the ideas, which are very clear, but in trying to predict which parts (composing reducers, passing state to components) would be animated by Javascript magic, and which were plain-ol-Javascript.

I found myself straining a little to memorize code snippets to get things started.

Once up and running, it's a breeze, though of course I agree with the common sentiment that it's too easy to overuse, and native React state too easy to underuse.

Re: MobX – Simple, scalable state management for React

#14

Post by jpatte »

Lazare wrote: post #3

I wrote a very large app in Knockout back in the day, and ran into significant problems with Knockout's computeds and the two way data binding. It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches wh…

I don't know what you call a "very large" app, but I have a fairly complex app relying solely on Knockout with hundreds of observables/computeds being triggered in real-time to update the state of the UI as users drag and drop visual elements and it works like a charm. The UI is never out of sync with the model. I'm using Knockout 3.0, maybe things improved since you wrote your app?

Re: MobX – Simple, scalable state management for React

#15

Post by gedy »

Lazare wrote: post #3

I wrote a very large app in Knockout back in the day, and ran into significant problems with Knockout's computeds and the two way data binding. It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches wh…

React and Knockout are different because of how they render to the DOM, not because of computeds and observable concepts. KO is glitchy in big apps because it's working with and modifying the actual browser elements. And React is a view renderer without strict requirements on how the data is modeled. It seems like a great fit for benefits from both.

Re: MobX – Simple, scalable state management for React

#16

Post by cageface »

tptacek wrote: post #13
diggan wrote: post #10

Earlier quoted context omitted.

I haven't used Moxb but I've used Redux a lot the last 6 months, building mobile apps and also a rewrite of our frontend at Typeform. I'm not sure how Redux could be considered complex, the API is very small and the ideas are small as well. There is really not much to learn with Redux. Redux is like literally 100 lines of code if you remove comments and simple sanity checks. Also, not sure what you mean with boilerpl…

Redux isn't conceptually complex, but I found it hard to get started with. The trouble I had wasn't the ideas, which are very clear, but in trying to predict which parts (composing reducers, passing state to components) would be animated by Javascript magic, and which were plain-ol-Javascript. I found myself straining a little to memorize code snippets to get things started. Once up and running, it's a breeze, though…

It gets really hairy when you have to weave in asynchronous actions and things like react-thunk or react-saga. By the time you've wrapped your head around those concepts as well the whole React stack doesn't feel quite as much like the breath of fresh air it does when you first start using it.

For my next Resct project I intend to go as far as I can with simple container components before I start pulling in the whole Redux toolkit.

Re: MobX – Simple, scalable state management for React

#17

Post by sotojuan »

cageface wrote: post #16
tptacek wrote: post #13

Earlier quoted context omitted.

Redux isn't conceptually complex, but I found it hard to get started with. The trouble I had wasn't the ideas, which are very clear, but in trying to predict which parts (composing reducers, passing state to components) would be animated by Javascript magic, and which were plain-ol-Javascript. I found myself straining a little to memorize code snippets to get things started. Once up and running, it's a breeze, though…

It gets really hairy when you have to weave in asynchronous actions and things like react-thunk or react-saga. By the time you've wrapped your head around those concepts as well the whole React stack doesn't feel quite as much like the breath of fresh air it does when you first start using it. For my next Resct project I intend to go as far as I can with simple container components before I start pulling in the whole…

This is why Ryan Florence (react-router, React Training) just made his keynote speech at the React Rally conference about people overusing Redux and not learning or wanting to use plain old React.

In his trainings he constantly sees people trying to rush React and asking him about Redux (which he doesn't cover).

Re: MobX – Simple, scalable state management for React

#18

Post by tptacek »

sotojuan wrote: post #17
cageface wrote: post #16

Earlier quoted context omitted.

It gets really hairy when you have to weave in asynchronous actions and things like react-thunk or react-saga. By the time you've wrapped your head around those concepts as well the whole React stack doesn't feel quite as much like the breath of fresh air it does when you first start using it. For my next Resct project I intend to go as far as I can with simple container components before I start pulling in the whole…

This is why Ryan Florence (react-router, React Training) just made his keynote speech at the React Rally conference about people overusing Redux and not learning or wanting to use plain old React. In his trainings he constantly sees people trying to rush React and asking him about Redux (which he doesn't cover).

This is also a drum that Dan Abramov (who created Redux) has been beating.

Re: MobX – Simple, scalable state management for React

#19

Post by tptacek »

cageface wrote: post #16
tptacek wrote: post #13

Earlier quoted context omitted.

Redux isn't conceptually complex, but I found it hard to get started with. The trouble I had wasn't the ideas, which are very clear, but in trying to predict which parts (composing reducers, passing state to components) would be animated by Javascript magic, and which were plain-ol-Javascript. I found myself straining a little to memorize code snippets to get things started. Once up and running, it's a breeze, though…

It gets really hairy when you have to weave in asynchronous actions and things like react-thunk or react-saga. By the time you've wrapped your head around those concepts as well the whole React stack doesn't feel quite as much like the breath of fresh air it does when you first start using it. For my next Resct project I intend to go as far as I can with simple container components before I start pulling in the whole…

It's interesting, I didn't find -thunk all that hard to grok, and in practice I was far less annoyed by that than I was by connect(). But I also found -thunk a refreshing change from what I'd been doing prior to redux (Flummox with async-await action creators).

Re: MobX – Simple, scalable state management for React

#20

Post by mboperator »

Lazare wrote: post #3

I wrote a very large app in Knockout back in the day, and ran into significant problems with Knockout's computeds and the two way data binding. It was great to start with, but as the app got larger and more involved, performance started to suffer (from all the different observables and computed triggering and retrigger on a change), memory leaks started to creep in, and eventually I started noticing weird glitches wh…

If selectors and reducers are a big pain for you, might I recommend the following library: https://github.com/mboperator/redux-modules

The motivation was to reduce boilerplate and improve the readability of redux state transformations. I've found that the number of files I need to touch to create an action drastically decreases.

At this point most of my development time is spent either in the module, the handler, or the saga.

Post reply on HN