Modifying state directly instead of using setState()

In React class components, you should never modify state directly by assigning to this.state. Here’s why and how to do it properly:

Why Direct Mutation is Bad

// ❌ Wrong - directly mutating state
this.state.counter = 1;

1. No Re-rendering: React won’t know the state changed, so your component won’t update
2. Async State Updates: React may batch multiple setState() calls for performance
3. State Consistency: Direct mutations can lead to hard-to-debug inconsistencies

The Correct Way: setState()

// ✅ Correct - using setState()
this.setState({ counter: 1 });

Key Characteristics of setState():

1. Triggers Re-render: React schedules a component update
2. Merges State: Only updates specified properties (shallow merge)
3. Can Be Async: React may batch multiple updates

Advanced Usage

1. Functional setState (when new state depends on previous state)

this.setState((prevState, props) => {
  return { counter: prevState.counter + 1 };
});

2. Callback after state update

this.setState({ counter: 1 }, () => {
  console.log('State updated:', this.state.counter);
});

Common Pitfalls

1. Async Nature:

   console.log(this.state.counter); // 0
   this.setState({ counter: 1 });
   console.log(this.state.counter); // Still 0 - hasn't updated yet!

2. Batching:

   // These may be batched into a single update
   this.setState({ a: 1 });
   this.setState({ b: 2 });

Special Case: Constructor

The only place where direct state assignment is acceptable is in the constructor (before the component mounts):

constructor(props) {
  super(props);
  this.state = { counter: 0 }; // ✅ Allowed here only
}

Modern Alternative: Function Components with Hooks

With React 16.8+, consider using the useState hook:

const [counter, setCounter] = useState(0);

// Update state
setCounter(1);

This provides a more straightforward way to manage state without the pitfalls of class components.