[bauerd]

>In the react world though you can’t mutate your data.

Wrong, you're free to mutate your data. What's immutable is the virtual DOM fragment that a component maps the data onto. If you want to manipulate the DOM directly (and it can make sense), how about not choosing a virtual DOM/diffing library?

>If you get 3 people react will end up re-rendering 3 times because of the code above.

Yeah, because the code above is obviously not a good idea. If you receive a list of people and loop over the members, each time triggering a rerendering, it's your fault?

>So what about trees of data with redux? The docs tell you try not have nested data. Instead put things in flat arrays and use indices to reference things in other flat arrays.

I'm not sure what part of the docs this refers to, but state in Redux is literally organised in a tree and you're free to choose data structures for the nodes that make sense. I've found that deeply nested structures make it more cumbersome to write reducers for.

>Why is the UI library dictating how we store and manipulate our data!!!

It does not do this, it's a virtual DOM/diffing library (!!!).

>Maybe someone needs to start the browser over.

This is a highly incoherent rant that mixes up criticism of immutable data structures, the Flow architecture, virtual DOMs and the Redux API. The quote above doesn't surprise me in the least.

Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?

[stickfigure]

I'm about 6 months into a React project (coming from Angular1) and honestly I find the OP's rant pretty coherent. React requires a preposterous amount of code to maintain state, and Redux doubles down on boilerplate.

In Angular-land you can just mutate some JS objects and the UI magically updates. I really miss that.

I picked React over Angular2 because the setup was simpler and I wanted to try out this new thing that everyone has been raving about. I have a lot of misgivings about the choice. There are some things I like about React, but I probably will not choose it for my next SPA. There's just too much typing.

[gr__or]

Redux is not intended to be THE state management lib for every possible use case. It sure can cover pretty much every case though as people tend to notice, that requires quite some boilerplate. For typical CRUD apps that stay in sync with the backend, I'd recommend going with MobX or GraphQL (Relay or Apollo on the client side). There you can directly mutate objects just like you're used to.

To reiterate what other people have said. This it not a problem of React, this is a problem of people blindly jumping on the Redux hype train, without doing the required reading into Redux and its use case.

[darth_mastah]

No matter what framework or library you choose, if you go past the to-do list project you will encounter certain pain points. I worked with jQuery when it was the new kid on the block, with Angular since it first came out and now with React. Every one of them gives you grief now and again. However if you develop pragmatically you learn how to avoid those pain points early on in the process even if it means investing some time. It will pay off later on. And if there is absolutely no way to mitigate the pain - just move on to another library.

It makes me sad to see people ranting about how much typing there is in Redux or Typescript or how much boilerplate and so forth. To me this behaviour screams immaturity, because I don't know how else to explain spending energy on wining instead of finding a solution. Especially, that you don't need to look far - take redux-actions for example. Nice and simple, makes all the heavy lifting for you. If that's not cool in your view how about you actually contribute and write something of your own, rather than moan?

[BigJono]

> I've found that deeply nested structures make it more cumbersome to write reducers for.

Well, that's kind of his point isn't it? It's no more difficult to update a deeply nested regular Javascript object. But it is more difficult to update a deeply nested Redux data store.

> Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?

I'd argue that Redux is not just "not a silver bullet", it's an arrow head shoved into the barrel of a gun. You might kill something with it, doesn't make it any good.

I agree completely with the rest of your points though.