Hacker News Reader

Comment by 010a | Hacker News Reader

I would argue that implementing it, especially in situations where you need to create a new reducer, requires a huge amount of boilerplate for something that feels like it shouldn't. Considering 75% of what you use redux for is getting and setting simple variables, I don't know why actions and reducers have to be so copy-pasty.

The core idea of Flux, and the theory behind Redux, is very simple. But I personally dislike Redux.

View on HN

The boilerplate is very intentional. If you want a framework that reduces boilerplate by doing some magic or having a more strict interface, then yeah absolutely, Redux isn't the right choice for you.

It is being compared to mobx. I am not sure how observables are magical.

Have you read the source? It's far heavier than redux. Computed properties and observables that can potentially change other observables sounds like a recipe for spaghetti IMO.

@observer seems like the same thing as connect(), but it passes down the entire state as context.

¯\_(ツ)_/¯

An observable cannot change as other. If you attempt it the mobx internals will throw an error. It's been the source of finding logical errors in my code. Also the size of the lib doesn't contribute to calling it magical. Something is magical when it is complex to reason about, due to taking arbitrary seeming decisions behind the scenes.

You should read some of the comments in that codebase. (Look for the constant MAX_REACTION_ITERATIONS). I don't know why you'd paint yourself into a corner like that.

Just curious, how can you test a mobx store independently? (Sans components)

That really depends on your architecture.

The way I have it setup, everything is in a central store, and the components only access it rather than have observables for any kind of local state.

Local state is handled with boring old setState calls, so the store and data-layer is totally independent of React, and can be tested without even importing the library.

> (Look for the constant MAX_REACTION_ITERATIONS)

Okay... that's interesting. It dates back to Feb. 2016th[1], and I'm not caught up with that version. My pull comes from January [2].

Giving it a brief look over, it looks like they changed the codebase to allow for reacts to trigger themselves. My version doesn't allow that. It's a fatal error instantaneously.

Presumably, this was done to let people write recursive functions.... but I'm not 100% sure this is a good idea.

Edit: I think my version implicitly has MAX_REACTION_ITERATIONS = 1, so observables triggering itself is an immediate error.

[1] https://github.com/mobxjs/mobx/commit/a38b6a8c255d772a79dadd...

[2] I know I should update, but I come from the boring Python world where you don't expect the internals of a library to change too drastically year to year.

>If you want a framework that reduces boilerplate by doing some magic or having a more strict interface

Having DRY code is not "magic".

Reply on news.ycombinator.com