But it is the first principle of Redux

The state of your whole application is stored in an object tree within a single store.[1]

Am I getting it wrong?

>I plan to put up “Design Goals” document in the repo

That would be great. The "why" is sometimes hard to understand.

[1]http://redux.js.org/docs/introduction/ThreePrinciples.html

>But it is the first principle of Redux

Redux is a very opinionated library and it is not related to React in any way. React does not officially endorse Redux. If (and that’s a big if!) React patterns don’t scale for you or if you personally prefer Redux to them, you can use it, but a Redux app !== a React app.

Which doesn’t mean either of them is the “right” or “wrong” way. Learn React first and try to use it. If you have issues related to state or if you’re just curious, you can also learn Redux to compare their approaches. If you like, you can combine them, or use them separately.

A part of React community, yes. Another part, no. Guess which part is vocal because they can write tutorials, examples, articles that generate clicks? ;-) I am as guilty of this as anyone of course, if not the most.

Obviously React has some deficiencies addressed by Redux. So does Redux have deficiencies addressed by React. Eventually some of the ideas from Redux might make it back into React.

However I suggest learning to build apps with React itself first before using more radical approaches like Redux. You’ll benefit immensely from knowing both ways. I would not necessarily put trust into articles saying “X is the best practice” or “Y is an inferior paradigm”. I would, however, listen to somebody who says “we tried X and Y, and here’s what worked best for us and why”.

>My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.

Ah okay, sorry then! These are both interesting, albeit different directions. I think it’s easy to misunderstand them as an “evolution” whereas it’s really a “fork” (in the traditional, non-technical sense). These are two separate ways, and both lead to interesting but different things.

I really like the state reducers.

I find internal state clumsy, beacause you have three kinds of functions around the very same state object - get initial state, get state after some props changed and get state after some user action. For simple cases they are very similar to repeatedly write, but still different to abstract out.

I hate putting everything in One-Rules-Them-All Redux Store (specially form input on each key press), beacause it creates too much little components to glue it all together - Action declaration, action generator, reducer implementation, projection from Store to component's props

I did not see any good solutions that take best of both approaches and I was tired searching. But I plan to wrap my brain around this and think about what exactly is bothering me and how to solve that. In first sight it is what I outlined in my first post. The next thing comes to my mind are Redux-style reducers for component's internal state.

    dispatch(action) {
      this.setState(prevState => reducer(prevState, action))
    }

ducks

Alternatives:

- internal state (sometimes useful, especially for small things that doesn't matter for your underlying data - eg, "is this part of the tree unfolded"). Preferably, with very little logic linked to that state. Note that it can bite you if you use something like redux-undo on your store and your internal state refers to the data controlled by the store.

- temporary stores (create a store with a callback function in an event handler, and feed it a callback that invokes an action on your main store)

- smaller, specialized stores that get a projection of the data of you main store (this gets a bit awkward with async actions)

I'm also trying to avoid fully-controlled text inputs with textareas, I use wrappers with local state which send their content via onBlur().

This leads to hilarious codebases where people dispatch actions in order to update input values or navigation dropdown open/closed states etc. Trivial apps that could be built over a weekend end up taking weeks to finish.

It's a sad reality but most people (including developers) take everything they read at face value and don't devote enough time to critical thinking. We should try to combat this.

I'm not saying it's your fault (it's not, you're great), but perhaps you should put a bit more effort into stating how what you're propagating is just one way of writing code and shouldn't be used in all situations (especially simple apps). I've actually seen you do that in a couple of places in the past few months and that's great.

I do feel a bit bad about sitting in my chair criticising while you're contributing with all this awesome stuff but you know... with great power comes great responsibility :-)

Redux manages the state of your application as a whole. But individual pieces within the page have no reason to know about the page state. Likewise, there's no reason for your Redux stores to concern themselves with the detailed workings of every component. Why should your app care what's going on inside a button or a menu? That leads to gigantic, overcomplicated states. Let the components manage things for themselves.

A good rule of thumb might be that if three layers of components need to know about a piece of data, it might be good to consider moving it into a store. But if it's only a component and its child components that need to know about it, you're not gaining much by moving it into stores--the stores and actions you'll have to implement are just added complexity. It's incredibly frustrating when I come across code where I have to push data through an action and a store and dispatch when a simple call to setState would have done all the same things faster and with less code.

It's my impression that a lot of people are coming from a Angular or Ember-ish background where they're building what amounts to single-page web applications. I'm building multi-page apps that have heavier-lifting back-ends, and React fills the space of building components that can be composed and embedded in the page.

When you're building a single-page app, stores make a great deal of sense. But when you're embadding components in a page, it doesn't make sense to use stores. Not only do I not want to have my components interact, I want to actively avoid having them interact, because that coupling would make the components non-reusable. So tying them to a global state presents serious issues for that model.

It occurs to me that this might account for our difference in perception of the importance of stores.

P.S. It's also worth noting that moving state out of a component and into a store is fairly painless. The reverse is not true; moving state out of a store and into component state is an extremely painful and error-prone process. So it makes sense to start with component state and move things into stores only as needed.

The slider offset is a very transient variable that is not really important. Next time you load an object from the database you'll just convert the value to a slightly different offset and nobody will notice. Are you going to store the offset in the big store?

First, thank you for all you do. Huge fan, and you're an asset to the community.

One question I have is around this quote:

> Learn React first and try to use it. If you have issues related to state or if you’re just curious, you can also learn Redux to compare their approaches.

I tried to go down this route with a new employee who I've positioned on a React project (mostly as means of exploration + learning in between other projects)

But as soon as I had to deal with fetching data from the server and pushing it back, I felt the need to jump into Redux. Yes, I could manage this in React, but as soon as I had two "pages" in my app, I feel it would become unwieldily note to use the Redux + Redux-Think (or Sagas) combo.

Am I wrong here, or am I just "comfortable" with Redux, and thus, not persuing the idea of trying to build a more featured app in pure React?