Controlled vs. Uncontrolled Components

Part 1: The Core Distinction: Who Owns the State?

At the heart of this topic is a simple question: for a given form input, where does its "state" or current value live? Is it held within the DOM node itself, or is it managed by React in a state variable? The answer determines whether the component is uncontrolled or controlled.

• Uncontrolled Component: The DOM is the "source of truth." The <input>, <textarea>, or <select> element manages its own internal state. React is unaware of the changes until it explicitly asks for the value, typically via a ref.
• Controlled Component: React state is the "source of truth." The value of the input is driven by a state variable (e.g., from useState). Every change to the input updates the state, which in turn causes the component to re-render and pass the new value back to the input.

To see these two patterns in action, the following video provides a concise, side-by-side code demonstration.

The data flow for each pattern is fundamentally different. This is often the most helpful way to conceptualize the distinction.

Part 2: Analyzing the Trade-offs

Choosing between a controlled and an uncontrolled approach is a classic engineering trade-off. You are balancing control and predictability against simplicity and performance.

The React documentation frames this concept more broadly. A component is "controlled" when its important information is driven by props from a parent. An "uncontrolled" component manages its own state internally. While our focus is on form inputs, this principle applies to any component. A Panel component with an internal isOpen state is uncontrolled; a Panel that receives an isOpen prop is controlled by its parent.

Let's dive into the specific trade-offs for forms.

Let's synthesize what we've learned from the video and the article into a summary of the trade-offs:

React's official recommendation generally favors controlled components because they align better with the declarative nature of the library. Having the form data handled by the React component makes the state more predictable and easier to manage.

Part 3: Deep Dive into Controlled Component Edge Cases

Your interest in the underlying mechanics is particularly relevant here. While controlled components are generally preferred, their implementation—where React hijacks the native input behavior—can lead to subtle but frustrating bugs.

The same article we just reviewed explores two excellent examples of this.

Let's break down these two issues, as they reveal a lot about the browser and React's interaction:

1. Cursor Jumping: When you type in the middle of an input, the browser natively handles keeping the cursor in the right place. In a controlled component, the flow is: keystroke -> onChange -> setState -> re-render -> value prop is updated. If setState is batched or asynchronous (which is common, especially with libraries like Redux or Valtio), there's a tiny delay. In that moment, React might re-render the entire input value. The browser, seeing a new value being programmatically set, loses its internal reference to the cursor's last position and defaults to placing it at the end. This is a classic conflict between the imperative browser DOM and React's declarative updates.

2. Broken Undo/Redo: The browser maintains a history stack for form inputs to enable undo/redo functionality. This stack is built on native user interactions. When a controlled component updates the value prop on every render, it's essentially telling the browser, "Forget what the user just did; here is the new value." From the browser's perspective, this isn't an incremental user change to be added to the undo stack. It's a programmatic replacement. As a result, the undo history is often wiped out, breaking Cmd+Z. In scenarios where rich text editing is crucial, this is a strong argument for using an uncontrolled component or a specialized library.

These edge cases are perfect examples of why understanding the "how" is critical. They are not React bugs, but rather inherent consequences of the controlled component pattern's architecture.

Conclusion

We've dissected the two primary patterns for handling form data in React. The choice is not about right vs. wrong, but about making an informed decision based on the specific requirements of your component.

Key Takeaways:

• Controlled vs. Uncontrolled: The core difference is the "source of truth." In controlled components, it's React state; in uncontrolled components, it's the DOM.
• Implementation: Controlled components use useState, value, and onChange. Uncontrolled components use useRef to pull data imperatively.
• The Trade-off:
  • Choose controlled for predictability, instant validation, and when the input's state needs to be shared or coordinated. This is the default React way.
  • Choose uncontrolled for simplicity, performance in high-frequency update scenarios, handling file inputs, or when preserving native browser behavior (like undo/redo) is critical.
• Under the Hood: The controlled pattern, while powerful, works by overriding native browser behavior, which can lead to subtle edge cases like cursor jumping and broken undo stacks.

What's Next?

In this lesson and the previous ones, we've seen how hooks like useState, useEffect, and useRef are used to manage logic within a component. Often, this logic becomes complex and repetitive. For example, you might have multiple controlled inputs that all need state, an onChange handler, and validation logic.

In our next lesson, we will learn how to implement a custom hook to encapsulate and reuse stateful logic between components. This is a powerful pattern that allows you to create your own hooks, like a useFormInput hook, to build cleaner, more maintainable, and highly reusable components.