Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Redux is like 200 lines of code and very explicit without any magic. What exactly is complex about it?

I think too often people don't appreciate that redux, like all frameworks is a trade-off and is often the wrong tool for the job. Speaking about it as if it's a generic framework to trade out for another framework is a sign that it's being selected for the wrong reasons.

If it's not making your life easier, you probably shouldn't be using it for that application. It's a really nice framing hammer, not a multitool ;)

When I got into front end, I used redux for a small SPA with about a dozen actions and didn't really get it. "I could do this with react and basic JavaScript. Why am I writing so much extra?" I refactored redux out and it was much better.

I have another application that interfaces with a number of APIs, is a very thick client and needs to recover from local storage on startup. Redux fit like a glove!

View on HN

I think a lot of the complexity comes from the incredible specificity of the docs. The authors intend to _teach_, which while great (thank you) it can seem overly complex for users who first land there.

I think a "Quick Start" section would solve a lot of the so-called "complexity" issues, showcasing a few common use-cases:

- Without React - With React

Put bare-bones code under each of those sections and then let the user learn the particulars as they come (and as their projects demand)

I'm currently the primary maintainer doing stuff with Redux docs. Right now my focus is on a tutorial series I'm writing for my own blog, but any PRs to help improve the Redux docs are absolutely appreciated!

Will give it a look tomorrow :thumbsup:

Without Redux - With Redux

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.

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.

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

Having DRY code is not "magic".

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.

Reply on news.ycombinator.com