5 ms·

I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle meth

by janci 10y ago

I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods. React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other way around. Also they will be called templates. We are getting back to good-old-days PHP-style webcoding, but with few HUGE improvements. 1. no globals, mostly pure functions 2. no business logic in templates, but in easy-to-reason-about redux-style state reducers 3. client-side rendering / isomorphic apps possible

jacobr 10y ago
Component state is hardly considered harmful. What has given you that impression?
- juanger 10y ago
  not exactly harmful, but in the docs they promote stateless functions by saying: "In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible." See https://facebook.github.io/react/docs/reusable-components.html#stateless-functions https://facebook.github.io/react/docs/reusable-components.ht...
  - petewailes 10y ago
    That's more because most components are render-focused, which means they're more concerned with props than with state. Of course, a particular render component might also have its own state (imagine a list with pagination for example), which isn't required by any of its parents or siblings. However, state is something on the whole that's required more often higher than lower in your architecture. I'm pretty sure that's what they're talking about here. Hope that helps.
danabramov 10y ago
>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.
smac8 10y ago
Not sure what you mean on component state, as I've never heard anyone say that is explicitly harmful, but I think what you might be getting at is the principal in react of creating MINIMAL state such that any logic - for example something that renders an item - can compute off that MINIMAL state, rather than creating a new state that's the result of processing that basic state. The example given in Thinking in React[1] is having an array in state, but computing it's length somewhere (say in render), rather than making the length of the array also part of the state. On this note, I find that I rarely use state in child components, because as much as possible I have functions that compute values off props and simply return that where I need them, rather than storing them as state variables. [1] https://facebook.github.io/react/docs/thinking-in-react.html https://facebook.github.io/react/docs/thinking-in-react.html
msane 10y ago
> easy-to-reason-about redux-style state reducers This buzz phrase "easy to reason about" is so popular in the React world. I feel like I'm the only one who finds it oxymoronic. Especially with regard to Redux, which I think is anything but. Angular 1/2, Ember, Backbone are all pretty "easy to reason about", so much so that it is rarely pointed out.
- mercurial 10y ago
  What do you find hard to reason about when it comes to Redux? There is some terminology, but the heart of Redux is a pure function that takes a state, new information, and returns a new state. That's hardly rocket science.
- szensius 10y ago
  You are definitely not the only one who has not found Redux "easy to reason about". I think the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications.
  - oldboyFX 10y ago
    > the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications. Well said.
natlee75 10y ago
As many others here have already pointed out, component internal state as a general concept is not by any means considered "harmful" and can often be quite useful. I was part of an open source component library project at my company where we used internal state for a number of those components to handle state that was likely to be unimportant to any consuming application. For example, our component equivalent of a drop-down menu has internal state to deal with whether or not the menu is expanded or not. This is not likely to be state that a consumer cares about -- all anyone really wants to do with this is pass in which menu item, if any, has been selected and to know when someone selects one of those options.

by janci 10y ago

jacobr 10y ago

Component state is hardly considered harmful. What has given you that impression?

juanger 10y ago
not exactly harmful, but in the docs they promote stateless functions by saying: "In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible." See https://facebook.github.io/react/docs/reusable-components.html#stateless-functions https://facebook.github.io/react/docs/reusable-components.ht...
- petewailes 10y ago
  That's more because most components are render-focused, which means they're more concerned with props than with state. Of course, a particular render component might also have its own state (imagine a list with pagination for example), which isn't required by any of its parents or siblings. However, state is something on the whole that's required more often higher than lower in your architecture. I'm pretty sure that's what they're talking about here. Hope that helps.

danabramov 10y ago

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

smac8 10y ago

Not sure what you mean on component state, as I've never heard anyone say that is explicitly harmful, but I think what you might be getting at is the principal in react of creating MINIMAL state such that any logic - for example something that renders an item - can compute off that MINIMAL state, rather than creating a new state that's the result of processing that basic state. The example given in Thinking in React[1] is having an array in state, but computing it's length somewhere (say in render), rather than making the length of the array also part of the state. On this note, I find that I rarely use state in child components, because as much as possible I have functions that compute values off props and simply return that where I need them, rather than storing them as state variables. [1] https://facebook.github.io/react/docs/thinking-in-react.html https://facebook.github.io/react/docs/thinking-in-react.html

msane 10y ago

> easy-to-reason-about redux-style state reducers This buzz phrase "easy to reason about" is so popular in the React world. I feel like I'm the only one who finds it oxymoronic. Especially with regard to Redux, which I think is anything but. Angular 1/2, Ember, Backbone are all pretty "easy to reason about", so much so that it is rarely pointed out.

mercurial 10y ago
What do you find hard to reason about when it comes to Redux? There is some terminology, but the heart of Redux is a pure function that takes a state, new information, and returns a new state. That's hardly rocket science.
szensius 10y ago
You are definitely not the only one who has not found Redux "easy to reason about". I think the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications.
- oldboyFX 10y ago
  > the concepts are somewhat straightforward, but in practice are a little harder to grasp, especially in real world applications. Well said.

natlee75 10y ago

As many others here have already pointed out, component internal state as a general concept is not by any means considered "harmful" and can often be quite useful. I was part of an open source component library project at my company where we used internal state for a number of those components to handle state that was likely to be unimportant to any consuming application. For example, our component equivalent of a drop-down menu has internal state to deal with whether or not the menu is expanded or not. This is not likely to be state that a consumer cares about -- all anyone really wants to do with this is pass in which menu item, if any, has been selected and to know when someone selects one of those options.