5 ms·

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

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

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.
- deleted 10y ago
  [deleted]
lcarlson 10y ago
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.

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.
deleted 10y ago
[deleted]

lcarlson 10y ago

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.