Comment by danabramov | Hacker News Reader

Comment by danabramov | Hacker News Reader

Parent Full thread

>First it was component internal state

You won’t find any place in React docs that claims internal state is harmful. There are some guides claiming that but this is not the official position (and I say this as author of Redux and a member of React team). We use state a lot at Facebook, and it’s a large part of what makes React useful.

>next thing will be the lifecycle methods.

Lifecycle methods are also fine. Sure, it’s best when there aren’t too many and they don’t do too much, but it’s a supported feature for a reason. It is occasionally super useful. They aren’t going away.

>React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation.

This is an explicit non-goal of React. We think stateful components with lifecycle methods are very useful. If you don’t agree, however, React is indeed not the best choice for you, as it does too much.

I’ve read a lot of misconceptions around React so I plan to put up “Design Goals” document in the repo so people can get a better idea of the direction that we’re moving into, and why.

>You won’t find any place in React docs that claims internal state is harmful.

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

I think you are confusing React with Redux. They are two very different things. You can use them together but Redux is not the “default” way of using React.

>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.

I had an impression, that React community (not the authors) considers Redux as an best-practice. 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.

>I had an impression, that React community (not the authors) considers Redux as an best-practice.

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 did. I started with React itself. Then I added Redux (first time, it was beacause of the project manager decision).

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.

I hope this helps:

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

Hmmm, that'd be sweet in a mixin...

ducks

I never put everything in the one-big-store that rules them all either, but you don't really need to do that.

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().

The majority of developers don't have the time or interest to dig deep into nitty gritties of the React community & ecosystem. They read articles including yours and quickly become indoctrinated into thinking how (for example) putting ALL state into a redux store is a proper way to work with React.

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 :-)

I can't speak for the community as I've been using React/Flux for under a year, but I think that Redux and other Fluxes serve a very different role from component state, and using Redux/Flux to store all your state will cause problems with both performance and code complexity.

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.

My observation is that going with local state is going to bite you sooner than later and in most cases having it in Redux Store from beginning is a good idea.

I recently made a slider in React/Redux. Imagine a slider that has a width of 200px but needs to report values from 0 to 100. (The width is governed by external factors, e.g. other sliders nearby that need to report a widger range, but must visually be of the same width.) This means that sometimes you may move the slider just by a pixel and need to register the movement, but the underlying value won't change. I.e. you have the slider offset and the actual value.

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?

This has not been my experience. I wrote a good amount of React before introducing any Flux at all, and I've been bitten far more by my mistakes where I added things to stores unnecessarily than I have been by cases where I kept things in component state. Your experience might be different from mine.

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.

Dan,

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?

I don’t know, whatever works for you :-) I’m just saying that both ways can work fine.

What are your thoughts on just simple es6 classes and mvc? View=React, c=es6 class, m=immutable js. I use page.js for my router and call it a day.

Reply on news.ycombinator.com