3.Managing State

  1. Reacting to input with state
  2. https://codesandbox.io/s/wnphcd?file=/App.js&utm_medium=sandpack - form with different event states
  3. https://codesandbox.io/s/wnphcd?file=%2FApp.js&utm_medium=sandpack // toggle className
  4. https://codesandbox.io/s/mnk8zj?file=/App.js&utm_medium=sandpack // edit profile hide show element
  5. Choosing the state structure
  6. https://codesandbox.io/s/mlsd2f?file=/App.js&utm_medium=sandpack -- flattening of nested object/array
  7. https://codesandbox.io/s/tn7xjq?file=/App.js&utm_medium=sandpack - single row highlight on hover
  8. https://codesandbox.io/s/z9djq3?file=/App.js&utm_medium=sandpack - simple to do
  9. https://codesandbox.io/s/8g3mcn?file=/App.js&utm_medium=sandpack - multi select multi line highlight
  10. Sharing state between components
  11. Preserving and resetting state
  12. Extracting state logic into a reducer
  13. Passing data deeply with context
  14. Scaling up with reducer and context

  15. Reacting to input with state

  16. In React, you don’t directly manipulate the UI—meaning you don’t enable, disable, show, or hide components directly. Instead, you declare what you want to show, and React figures out how to update the UI.

  17. When developing a component:
  18. Identify all its visual states.
  19. Determine the human and computer triggers for state changes.
  20. Model the state with useState.
  21. Remove non-essential state to avoid bugs and paradoxes.
  22. Connect the event handlers to set state.

  23. Choosing the state structure

  24. Group related state. If you always update two or more state variables at the same time, consider merging them into a single state variable.

    • Another case where you’ll group data into an object or an array is when you don’t know how many pieces of state you’ll need. For example, it’s helpful when you have a form where the user can add custom fields.
const [x, setX] = useState(0);
const [y, setY] = useState(0);
 -------- to ------>>>>>
 const [position, setPosition] = useState({ x: 0, y: 0 });
  • Avoid redundant state. If you can calculate some information from the component’s props or its existing state variables during rendering, you should not put that information into that component’s state.
    • This form has three state variables: firstName, lastName, and fullName. However, fullName is redundant. You can always calculate fullName from firstName and lastName during render, so remove it from state.
    • const fullName = firstName + ' ' + lastName
    • As a result, the change handlers don’t need to do anything special to update it. When you call setFirstName or setLastName, you trigger a re-render, and then the next fullName will be calculated from the fresh data.
    • Dont mirror props in state
    • the color state variable would not be updated! The state is only initialized during the first render.
    • “Mirroring” props into state only makes sense when you want to ignore all updates for a specific prop. By convention, start the prop name with initial or default to clarify that its new values are ignored:
  • Avoid deeply nested state. Deeply hierarchical state is not very convenient to update. When possible, prefer to structure state in a flat way
  • If updating deeply nested state is complicated, try flattening it.

  • Sharing state between components

  • Preserving and resetting state
  • Extracting state logic into a reducer
  • Passing data deeply with context
  • Scaling up with reducer and context