4 ms·

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

by janci 10y ago

>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 http://redux.js.org/docs/introduction/ThreePrinciples.html

danabramov 10y ago
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.
- janci 10y ago
  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.
  - danabramov 10y ago
    >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.
    - janci 10y ago
      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.
      - danabramov 10y ago
        I hope this helps: dispatch(action) { this.setState(prevState => reducer(prevState, action)) }
        assertchris 10y ago
        Hmmm, that'd be sweet in a mixin... ducks
      - mercurial 10y ago
        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().
  - kerkeslager 10y ago
    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.
    - methyl 10y ago
      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.
      - Mikhail_Edoshin 10y ago
        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?
      - 10y ago
- truebosko 10y ago
  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?
  - danabramov 10y ago
    I don’t know, whatever works for you :-) I’m just saying that both ways can work fine.
deleted 10y ago
[deleted]

by janci 10y ago

danabramov 10y ago

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.

janci 10y ago
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.
- danabramov 10y ago
  >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.
  - janci 10y ago
    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.
    - danabramov 10y ago
      I hope this helps: dispatch(action) { this.setState(prevState => reducer(prevState, action)) }
      - assertchris 10y ago
        Hmmm, that'd be sweet in a mixin... ducks
    - mercurial 10y ago
      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().
- kerkeslager 10y ago
  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.
  - methyl 10y ago
    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.
    - Mikhail_Edoshin 10y ago
      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?
    - 10y ago
truebosko 10y ago
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?
- danabramov 10y ago
  I don’t know, whatever works for you :-) I’m just saying that both ways can work fine.

deleted 10y ago

[deleted]