State vs. Props

A components state and props do share some common ground:

  1. Both are plain JS objects
  2. Both can have default values
  3. Both should be accessed/read via this.props or this.state, but neither should be given values this way. I.e., both are readonly when using this.

However they are used for different reasons and in different ways.

Props:

  1. Props are passed into a component from above, either a parent component or from the starting scope where React is originally rendered.
  2. Props are intended as configuration values passed into the component. Think of them like arguments passed into a function (If you don’t use JSX that is exactly what they are).
  3. Props are immutable to the component receiving them. I.e., don’t change props passed to a component from within the component

State:

  1. State is a serializable representation of data (a JS object) at one point in time that typically is tied to UI
  2. State should always start with a default value and then the state is mutated internally by the component using setState()
  3. State can only be mutated by the component that contains the state. It is private in this sense.
  4. Don’t mutate the state of child components. A component should never have shared mutable state.
  5. State should only contain the minimal amount of data needed to represent your UI’s state. It should not contain computed data, other React components, or duplicated data from props.
  6. State should be avoided if at all possible. I.e., stateless components are ideal, stateful components add complexity. The React documentation suggest: “A common pattern is to create several stateless components that just render data, and have a stateful component above them in the hierarchy that passes its state to its children via props. The stateful component encapsulates all of the interaction logic, while the stateless components take care of rendering data in a declarative way.”