Comment by acemarke | Hacker News Reader

Comment by acemarke | Hacker News Reader

Whenever a Redux thread pops up, there's inevitably complaints about "boilerplate". I'd like to pre-empt those complaints a bit by pointing out that, per part 2 of my post, it's entirely up to you how much abstraction you use in your own Redux app. If you want use Redux for a particular use case, someone has probably already written an addon or utility to help solve that problem, and I've got them listed in my Redux addons catalog [0].

If you don't want to edit multiple files, use the "ducks" pattern to put actions and reducers in a single file [1]. If you don't like writing action constants by hand, use one of the dozens of action/reducer generation utilities out there [2] [3]. If you don't want to manage normalized data by hand, there's many addon libraries to help with that [4]. I specifically show off one of them, Redux-ORM [5], in my "Practical Redux" tutorial series [6].

I love all the tools and addons that people are building on top of Redux. One of my favorite quotes is from a Redux issue thread:

> Redux is a generic framework that provides a balance of just enough structure and just enough flexibility. As such, it provides a platform for developers to build customized state management for their use-cases, while being able to reuse things like the graphical debugger or middleware.

A few months ago I opened up a Redux issue thread to discuss further ways that we could help make it easier for people to use Redux, and solve complaints about "boilerplate". The discussion kind of trailed off, but I would love to have more discussion and ideas for building useful new tools on top of and around Redux to help people solve problems and build useful applications. Please join the discussion here: https://github.com/reactjs/redux/issues/2295

[0] https://github.com/markerikson/redux-ecosystem-links

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

[2] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[3] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[4] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[5] https://github.com/tommikaikkonen/redux-orm

[6] http://blog.isquaredsoftware.com/series/practical-redux

My only criticism about these tools/addons is that you're multiplying your dependencies to solve an "issue" that could have been entirely avoided by choosing a state management design that is more suitable for the situation. Most developers default to Redux without acknowledging the costs to using it.

Shameless plug: I created React Axiom for those who want a lightweight model pub/sub render paradigm with React:

https://hackernoon.com/introducing-react-axiom-84bf37a50adb

https://github.com/wgoto/react-axiom

Perhaps redux really might benefit from communicating heavily with beginners.

Well, I do spend a ton of time answering questions from Redux beginners in many places online: Reactiflux, Stack Overflow, Reddit, etc. That's why my first contribution to Redux was writing the Redux FAQ [0], because I kept seeing the same questions being asked over and over. Ditto for the "Structuring Reducers" docs section as well [1]. So, I'd say I've got a pretty good idea what kinds of questions people are asking.

The docs themselves are written in a very "from first principles" style. For example, the page on "Middleware" starts by trying to show various ways to solve the problem of logging all actions, and iterates from "monkey-patching the store" up to a reusable system for wrapping `dispatch`. Some people find this approach very helpful, others don't. As Dan commented during the original development process:

> So hard to write the new docs. Many different audiences to cater to. Should make sense to: Flux beginners, FP people, FP people who don't get Flux, Flux people who don't get FP, normal JS people too. Flux people: “is this proper Flux?” FP people: “is this that weird thing called Flux?” Normal people: “why not Backbone”

Now, at this point, far more people are familiar with Redux than with "Flux", so perhaps the goal of making the docs understandable and relatable to Flux concepts isn't as important.

Most of my work around Redux has been improving the docs, writing my own tutorials and explanations on my blog (like this post), and answering people's questions elsewhere. I'm always happy to work with anyone who wants to help improve the Redux docs, and I'm totally open to suggestions and pull requests.

[0] http://redux.js.org/docs/FAQ.html

[1] http://redux.js.org/docs/recipes/StructuringReducers.html

I think you're doing great work and you are to be thanked.

Yeah you help so many people, thank you for all you do!

Mobx is an alternative. Simple and less boilerplate.

An underrated alternative, at that. I had a great experience transitioning from Redux to MobX.

This! I feel like a broken record the amount of times I urge people to try MobX, but genuinely I think everyone I know who has tried it has been so pleasantly surprised at how quick and easy it is to work with and use effectively, compared to Redux. Personally, I reckon I can build stuff out which uses a reasonable amount of state at least twice as fast with MobX, and the code feels more maintainable as there's less of it, which as a freelancer is huge.

That's not to say Redux is bad or there is no value to learning it though. It presents a really interesting take on state management and really opened my eyes to a huge amount of concepts. I'm just not sure I would want to go back to a heavy Redux project again having used MobX!

This comment is always the first, every time, but they're both very different. Mobx is mutable binding, redux is one way, functional data flow. They have their tradeoffs, but when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place. YMMV.

The crazy state tree in redux is what made me go to mobx. I had events firing off updating multiple redux functions. It was very difficult to understand the flow. Mobx has simplified my changes to one place. To me they both the same managing client side state.

Mobx vs redux is probably not the right comparison here though. Mobx comes bundled with 'computed' and encourages most state to be handled there.

Redux doesn't have this, instead libs like reselect fills space.

My experience with redux was frustrating in the way you explained, but once I "got" how to defer all state to reselect instead of trying to do things with reducers it got significantly simpler.

My frustration wrt redux was organising the file structure where to place actions reducers. Otherwise it was a joy to work with. I considered it very simple and easy to work until I found mobx.

The two typical approaches are "file-type-first" (separate folders for "actions", "reducers", "containers", etc), and "feature-first". I've got articles discussing various React/Redux project structure approaches at https://github.com/markerikson/react-redux-links/blob/master... .

I have done both approaches, ducks, slight variation on ducks all running on production apps. Still not satisfied.

I have referred your links. Thank you btw.

> I look at mobx I get reminded of..

Looking like, and being like are two different things :) Mobx reminds people (rightfully) of Meteor, Knockout, Angular etc, but when working with it you will see it is quite a different best. Just like Redux will remind people of flux, but that doesn't mean people shouldn't try Redux because e.g. Facebook Flux didn't work out.

> they're both very different

Yes, but they exist to solve very similar problems.

> when I look at mobx I get reminded of managing crazy state trees in ember and why I went to react/redux in the first place.

You may find it feels differently in practice. Because when I look at redux, I get reminded of managing crazy state trees in redux, and why I went to react/mobx in first place. :)

To be sure, Redux has strengths too, and there are tradeoffs. But I don't think that a brief "mobx looks like ember!" really conveys much, and I think the number of people who have been happy after switching from redux to mobx further undercuts such easy dismissals.

It deserves to be first, because most people jump into redux because it seems like you're supposed to use it. Also I don't think I agree with the claim that they are very different. In theory, yes. In practice, I use it to solve the same problems in generally the same way (action driven updates, one-way data flow rendering), but with less boilerplate and (for my use cases) better performance. YMMV is fair, but anyone doing serious react work should be at least familiar with both.

But it's a little ridiculous when you can't even mention Redux without MobX being dropped.

Also an important thing to note is that Redux is fundamentally designed to lend itself to one-way data flow with a well-abstracted barrier between global state and your components. Yes, you can use MobX to accomplish the same thing but the pattern is fundamentally less obvious especially for someone new to React.

> But it's a little ridiculous

That's the point I'm contending: Its not ridiculous because its not obvious that its an alternative. And not just an alternative, but a much much simpler alternative for many use cases. I absolutely agree its annoying, and I'll have to be that annoying guy for a while. Because I can't stand seeing people spend time on clever solutions to problems that, with mobx, you may not have.

You'd have a point if the article was intended for people trying to bootstrap a React stack but this is specifically a deep-dive on Redux. It's equivalent to people proselytizing Rust in any thread that mentions Go. Believe it or not some of us are not ignorant -- we know what MobX is and still choose Redux every time.

Actually it's a response to a response about using libraries to help with redux boilerplate. Depending on your scenario, mobx might reduce your boilerplate and your dependencies at the same time. That's absolutely appropriate context. And again while I appreciate not wanting to see those comments if you already know about mobx, not everyone does. I didn't. And I'll forever appreciate running into those comments myself. This isn't a go rust comparison (languages designed for different problems) -- it's a discussion about state management in a ui. I'm sure mobx won't be the only alternative brought up. Thats IMHO a good thing.

Redux is an alternative. Easy to reason about and debug.

There is not goodness or evil. There are the variant tools for accomplishing variant tasks. I tried to use Redux, but I didn't recognize how to easily build scalable apps. At the same time, I performed the task with mobX, really easy and with zest. But this is my case. You can get an opposite result

Reply on news.ycombinator.com