4 ms·
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 fe
by 010a 10y ago
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.
- Waterluvian 10y agoThe 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.
- true_religion 10y agoIt is being compared to mobx. I am not sure how observables are magical.
- atoko 10y agoHave 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. ¯\_(ツ)_/¯
- true_religion 10y agoAn 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.
- atoko 10y agoYou 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)
- true_religion 10y agoThat 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/a38b6a8c255d772a79daddb218e964c16629b6f9 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.
- coldtea 10y ago>If you want a framework that reduces boilerplate by doing some magic or having a more strict interface Having DRY code is not "magic".