Hacker News Reader

Comment by gravitronic | Hacker News Reader

It's really disappointing to me to see Redux being the "defacto standard" for React applications. It's overly decoupled for simple applications, which makes it harder to reason about the application. It also doesn't help that the Redux codebase itself is hard to understand.

It is only a tool you should reach for after you find you need it. Too few developers approach software development with this level of pragmatism and instead we get "use X because it's being used". I guess you need to understand the tool to know when to use it - but that doesn't mean it should become the "defacto standard".

Ironically Redux is being coupled with React, which is a great library for structuring UI into components and resulting it simpler to understand code.

View on HN

While I understand your point, that's not entirely true; Redux itself is just a state management library, and thus _completely_ decoupled from React. You can use it with any other library/framework. In order for Redux to work with React, you need the _connector_ library, "react-redux".

Furthermore, Redux itself is a relatively small library, written in a heavily functional style. True, this may be hard to wrap one's head around for developers new to this, but I can think of no better place to learn due to not only the small size, but a lot of documentation and _very_ active involvement (in GH issues and StackOverflow) by it's author.

Not counting other parts of its API like combineReducers and subscribing listeners, Redux is essentially..

function createStore(reducer, initialState) { let state = initialState; return { dispatch(action) { state = reducer(state, action); }, getState() { return state; } } }

It's quite simple.. and yes, it should only be used when needed, but the whole implementation of the Redux part of an app can exist in a few lines in a single file.

Sorry, the formatting for that didn't come out right

You need four-spaced indents to create code blocks.

I'm a little confused by what you're trying to say, so help me out here. You say "it's overly decoupled for simple applications" and then "it is only a tool you should reach for after you find you need it." This would imply that you view Redux as a tool that primarily helps maintain larger React applications -- does that mean you think it doesn't make sense as the defacto standard as compared to, say, Flux? Or that there shouldn't be a defacto standard, or that neither of these is a good enough defacto standard?

I'll take this as an opportune time to link to two very helpful and useful posts about Redux from its author (Dan Abramov) about upsides (http://stackoverflow.com/questions/32461229/why-use-redux-ov...) and downsides (http://stackoverflow.com/questions/32021763/what-could-be-th...) of using Redux.

Namely, I see Redux offering a nice advantage over flux in encouraging reducer composition (and functional purity) for modularity. "This pattern also enables wonderful features like no-user-code undo/redo. Can you imagine plugging Undo/Redo into a Flux app being two lines of code? Hardly. With Redux, it is—again, thanks to reducer composition pattern. I need to highlight there's nothing new about it—this is the pattern pioneered and described in detail in Elm Architecture which was itself influenced by Flux."

In short, the key value add for Redux, is not necessarily that it's (overly/inadequately) decoupled, but that it is necessarily forcing a decoupling via functional purity for the /purpose/ of modularity. That is, it is taking a more functional approach to state management for React components, favoring the event log paradigm rather than black box paradigm. This brings with it the ability to be "designed with use cases such as logging, support for Promises, Observables, routing, immutability dev checks, persistence, etc, in mind." Of course, these aren't impossible with Flux, but these things follow intrinsically from Redux.

Take my opinion with a grain of salt because I'm not super experienced with Redux yet, but I really like what I've seen so far playing with it.

I believe what he is trying to say is this:

It will take a person a couple of days to "grok" Redux, and a quite a bit longer to fully understand the ins and outs so one can make informed, confident decisions on how to solve problems "the Redux way".

Now you gain "cool" things by doing it, but here is the catch: Is the benefit worth the time investment to get there?

His argument is that for a lot of simple apps it isn't. You get very far with plain React, and a project has to have significant complexity to pay back the costs of fully understanding Redux.

I would argue a lot of people picking the React ecosystem make the mistake of choosing too much architectural complexity, not too little.

The extreme pluggability helps to broaden usage of Redux. But it is overkill for many projects. Decoupling is important, but it is not free (see parts of the Java ecosystem).

Devs should consciously decide what to introduce, and leave out stuff that simply doesn't increase development efficiency given the nature of their project.

Another commenter added the sentence I wish I had put in the original post. What I meant to say was, start with mostly pure components and just hold state in some top-level react components. Don't use react or flux. React makes it easy to share state between parent and child using props and callback registration which is perfectly fine to start.

When you find it hard to understand your state management within some parent react containers, or you're sharing a lot of state between siblings, consider flux or redux. Not before.

I think the functional style used in the redux codebase makes it a bit less obvious for those not accustomed to the style.

But it's really extremely simple. The terminology is perhaps more abstract than one might prefer, but I have yet to think of a way to improve upon it.

Also, if you let most components be pure, it's easy to start with a stateful component or two and then add redux later.

I really wish I had included your last sentence in my original post. Start with pure components and just React.

I think that's the best practice anyway.

MobX is a nice alternative paradigm to Redux that is gaining traction in the React community. It allows you to declare your data as observable, so that components can update automatically to changes.

https://github.com/mobxjs/mobx

Thanks so much for sharing this, it's exactly what I've been looking for, coming from working with Meteor for a while.

this is looks really sweet. Is there a list anywhere of what type of app makes sense with mobX vs redux?

I guess the "predictable single state container" is the key of its success as well as its great presentation videos.

Reply on news.ycombinator.com