Hacker News Reader

As a contrary opinion, I find Redux simplifies my react projects by virtue of having a standardized set of practices for handling state. The flux pattern in general is amazing, and I always wrote spaghetti, passing props everywhere, prior to discovering it.

After I switched to a 3 layer architecture (1. root component, 2. screen components, 3. ui components) I just had to gather data asynchronously in the screens and pass it into the UIs via props and that was it. No spaghetti, no Actions/Reducers.

I'm not saying this works for all apps, but I got pretty far with it.

3-tier on the client :)

Do you have an example somewhere on-line? I'm also not familiar with the term "screen components"

On mobile apps, the "pages" are called "screens" it's just the main UI container that gets replaced if you switch between screens

Ah, that makes sense. Thanks!

Agreed. Half the problem with Redux is technical, the other half is political.

Up until recently, the maintainers of Redux have neglected to meaningfully rein in the hype. If your react app is "complex" and "depending on your usecase"[1], redux must be used. Which is why the very first tutorial in its documentation is a... TODO app. A basic concept deliberately over-engineered to fit a framework that isn't suppose to handle "simple" apps. What?

Developer under great social pressure must resolve this glaring dissonance themselves. Developers who may feel more insecure in their knowledge of front-end engineering than they would like to admit. [2]

Well, for these developers, it can't be that they're not be "smart" enough. On the contrary, with some mental gymnastics [3], this "smart" framework will solve their "smart" problems, and then they will be "smart". The unspoken corollary is, of course, that anyone who disagrees with the "smart" framework" is not "smart".

What begins as misleading by the maintainers creates poison in the enterprise. Suddenly, this popular framework becomes the norm, as team after team is forced to conform, applying this "smart" framework to domains that aren't explicitly forbidden by the docs, to consistently, poor results.

Thus the driving force behind Redux became the deep, deep denial of insecure engineers, imprisoned by their own monoliths. Finally, there's a backlash. Without strong-technical-merits or clear-headed communication by the contributors, Redux will likely deflate and be limited to legacy code and the few cases it supports tremendously well.

Essentially, for those who've been around the block, Redux is to React what AngularJS 1.0 was to JS frameworks. A shame that we had to suffer through this cycle again.

[1] Dev-speak for "If you know what's good for you"

[2] As said recently, "Most Developers would not hire themselves"

[3] The test for this is if the Redux TODO app makes sense to them.

"Up until recently"

I wrote this a year and a half ago: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

I have respect for your work and your writing. But neither your blog nor the OP's is the source-of-truth. It's the documentation which is why I qualified my statement with "meaningfully".

Controlling the hype bubble would have meant rewriting the introduction of the docs, for example, replacing the TODO app with something actually intelligible. This drastic act would also have required buy-in from all the maintainers-- one of whom just posted an article protesting too much the decline of the framework in question.

From an outside's perspective, the damage control seems too little, too late.

And just what exactly is wrong with the TODO example? What's "unintelligible" about it? What do you think would make a better example?

Recently? Dan told people to consider not using Redux as early as 2016: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

I _completely_ disagree. Dan has spent _far_ more time telling people not to automatically reach for Redux than he _ever_ spent trying to market it. And what other library has ever had to have its maintainers spend more time telling people _not_ to use it, rather than promoting its use?

As for the examples: the "TodoMVC" example was already well-established as a common way to showcase JS MVC frameworks by the time Redux came out, so it was a natural choice for the Redux tutorial. We do have several additional examples in the repo, and the "Advanced" docs section builds out a small Reddit client to demonstrate working with async logic.

Docs writing is _always_ hard. As Dan originally said when he was writing the docs [0]:

> 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, I'd say that the JS landscape has definitely changed since the docs were written in 2015, and I'm open to ideas for revamping them. But, you also need to illustrate the basic concepts and workflow of a tool without getting bogged down in irrelevant details.

Finally... what "domains should be forbidden by the docs"? I've talked to people who have put just a few bits of data into Redux, and others who have opted to put literally _everything_ in their app into the Redux store. Both are viable approaches. Why (and how) should we say "no, don't do X with Redux" that way?

If you have specific concerns about the docs, or the way Redux is described and taught, _please_ don't just complain! I'm _always_ open to suggestions for improving the docs and the Redux ecosystem. Please give us some positive contributions and help us make things better for everyone.

[0] https://twitter.com/dan_abramov/status/622567874796855296

Have you ever heard of "Negate the frame, Activate the frame"?

Well, the headline you chose will hearten the faithful and give pause to everyone else. That plus the defensive tone of the article, sabotages the very framework you're championing. In my opinion, you should have have ran it all by Dan or other maintainers before publishing.

More worryingly is your response to the critiques of this thread. If my concerns were so wrongheaded and just so darn disagreeable, shouldn't you have simply ignored them? Or wait and see if they were validated by others?

Unless, if course, I'm giving voice to a suppressed thought, something that is already known but refuses to be known. Maybe that would explain the lashing out. I don't know.

I just don't have the same emotional investment in Redux. All I'm seeing the same worn-out hype-cycle playing again and again.

> More worryingly, however, is your response to the critiques of this thread. If my concerns were so wrongheaded and just so darn disagreeable, shouldn't you have simply ignored them? Or wait and see if they were validated by others?

I found the response to be quite reasonable, and certainly not worrying.

Why would it be a good idea to ignore people that disagree with you? It seems like it would be better to provide rational counter arguments, in the hopes of starting a useful discussion.

I have used Redux on a few projects, largely due to the hype (I.e., good recommendations from others in the community) surrounding it. Without intending to I ran into several discussions on SO and Github where Dan explained why people may not need redux. I think this is a very nice thing, and I think it is unfair to blame Dan or other developers for not reining in the hype more.

I do agree that the title of the article is a bit alarmist and perhaps counter productive.

I will admit to deliberately choosing an _ever_-so-slightly clickbait-y title to get people's attention :) But given the kinds of questions I've seen thrown around, I think it was legitimate as well.

Ignore concerns, not people. And only if those concerns are objectionable and unvalidated by others.

A good example of how to ignore concerns would be comparing Dan's responses here with that of Acemarke's. Dan's is to-the-point and confident, whereas Acemarke's is... markedly less so.

Really, the issue here is not how one developer communicates but how they communicate as a team. It's obvious that this self-damaging article wasn't formally approved by every Redux stakeholder-- but I also recognize that no one on the team expected for this to happen.

I'm very confused by your response here.

I've found a nice niche answering people's questions about React and Redux. I spend a lot of time in the Reactiflux chat channels, as well as a variety of other platforms (Reddit, HN, SO, Twitter, etc). I see questions, my natural impulse is to try to respond and answer them.

Dan Abramov and Andrew Clark created Redux, but now both work at Facebook and are no longer active maintainers. Dan handed over the keys to Tim Dorr and myself. While we don't have any formal division of labor, the typical pattern is that Tim takes care of most of the actual code tasks (merging fixes and publishing releases), and I handle most of the docs stuff and interact with people using it.

None of us have any particular veto over what the others do, and I don't see why I should have "run my post by them" before publishing it.

Yes, the article's tone was defensive, because I've been seeing the same questions, concerns, and FUD get tossed around. So, I was trying to answer those questions and clarify the situation. Most of the feedback I've gotten on the post has been quite positive, along the lines of "Thanks for helping clear that up!".

Maybe responding to you was a bad idea. I dunno. I just get frustrated when I see people complain about things without actually trying to make them better. As my mom told me dozens of times growing up: "You've stated the problem, now state the solution".

So, I'm not "lashing out", and I'm not saying your concerns are "wrongheaded". I'm trying to understand what the actual specifics are that you're concerned about, and find out how we can make things better going forward.

Your response is downright baffling. Really reads like someone in the middle of a manic high, that's how bad you misread the situation.

What I like in redux is not redux, it's everything built on it. Redux-form, redux-saga, react-redux-router, redux-persist...

Sure thing.

That's what I hear from every Redux proponent.

And I guess if you put in the time and became a Redux pro, there is no reason to switch.

But if you're starting out or have to work with non-pros, you're probably better served with unstated.

I'd have trouble seeing how I would do as good with Unstated as with Redux, but I have lot of experience with the later and zero with the former so you might very well be right!

Redux is more powerful, but the question is simply, do you always need that power?

If you're a single dev who knows Redux or working in a project with Redux pros, I'd say go for it, you invested your time into it, why not use it.

I think the opposite, redux-form for example is an over engineered way to handle forms. And not let me talk about react-router-redux.

This is actually my problem with redux - developers tend to put everything in the store.

I've used it primarily for manaing logged in user info. It's one of the few bits that is useful globally.

Genuine question: why not have a singleton service and store/get data from there(Just like angular services)

The idea is to have a single immutable data store. Immutability gives you, among other things, easier time debugging and reasoning. Having a single, global data store means that the entire state of your application can be managed centrally. There are no seemingly unimportant variables hiding anywhere that would drive your app, it's all in one place.

You can do that, but you will need to find a way to re-render the components which use that service, after something changed.

I think this works well for Angular, because it's based on observables. Rendering is just a function from state->ui. If they build their state-container on observables too, the re-render will follow implicitly by subscribing to it.

I think that's what mobx is all about. I create a simple Javascript class called WhateverStore and make it observable. Then all the UI components are observer of an instantiated WhateverStore and that's about it.

Just do it the React way and re-render everything by calling ReactDOM.render() again. In most cases that is fast enough.

Rendering in React is based on state and props. If you want to trigger a render, you need to change one of these.

If you base it on some external entity, you need to trigger a render manually.

These state libraries usually let you wrap your component in another component, that passes the state down as props, so when the state changes, new props are passed down and your component automatically renders with the new state.

What I like about Redux is the conventions in place to update the store from a number of places. I currently work on a complicated CRM with state needing to change from a number of places. Having a convention and having the ability to update state and manage side effects with sagas has been game changing.

If you're making a todo app, yeah sure, no redux. Creating an app without conventions to manage state? good luck making all of those decisions.

It seems interesting. I have one code reading issue, could anyone be so kind to explain it?

I read things like: <Subscribe to={[CounterContainer]}>

Why are [ ] needed? And what do [ ] mean here? I thought { } were enough for evaluating code.

It looks like Subscribe's `to` prop expects an array. So, `[CounterContainer]` is just an array with a CounterContainer in it.

The `{ }` that wrap it are just part of the syntax of passing props. If you wanted to pass an object literal to a prop, you'd have to double-up the curly braces:

  <div style={{ color: 'white' }} />

And strings can be passed with or without curly braces:

  // both of these are fine:
  <div id='foo' />
  <div id={'foo'} />

They are used to create arrays. You are able to subscribe to multiple containers:

  <Subscribe to={[CounterContainer, SomeOtherContainer]}>
      {(counter, someOther) => ()}
  </Subscribe>

I believe that the [] indicate an array.

Ah, right! It just evaluates to JS, fair enough. Thank you all!

Almost. It evaluates JS expressions (not statements). It's a minor distinction but trips a lot of people up.