React Component Patterns

A controlled component exposes a value prop and an onChange callback so the parent owns the state entirely. This is React's "single source of truth" contract — the component never holds private internal state for the value it displays.

// Controlled input component
function TextInput({ value, onChange, placeholder }) {
  return (
    <input
      type="text"
      value={value}
      placeholder={placeholder}
      onChange={(e) => onChange(e.target.value)}
    />
  );
}

// Parent owns the state
function LoginForm() {
  const [email, setEmail] = useState('');

  return (
    <TextInput
      value={email}
      onChange={setEmail}
      placeholder="Email address"
    />
  );
}

• Fully controlled: parent passes value and onChange — no internal state for the value.
• Uncontrolled fallback: omit value and use a ref via useRef for one-time reads (e.g., file inputs).
• Validation and transformation happen in the parent's onChange handler before state is updated.

• At an advanced level, the interesting problem is not wiring a parent and child through Context — it is making the wiring type-safe and resilient to consumers reordering, omitting, or wrapping children. Start by typing the context value precisely and refusing a default object that could silently mask a missing provider.

  type SelectContextValue<T> = {
    value: T;
    onChange: (next: T) => void;
  };
  
  function createSelectContext<T>() {
    return createContext<SelectContextValue<T> | null>(null);
  }
  

• A generic context factory lets Select<string> and Select<number> both get full type inference on value and onChange, instead of widening everything to any the way a single shared context would.

  const SelectContext = createSelectContext<string>();
  
  function useSelectContext() {
    const ctx = useContext(SelectContext);
    if (!ctx) throw new Error('Select.Option must be used inside <Select>');
    return ctx; // narrowed to SelectContextValue<string>, never null past this line
  }
  

• Context-based implicit sharing is convenient but invisible — a consumer cannot tell from JSX alone which children are required versus optional. React.Children.map with cloneElement is the explicit alternative: the parent injects props directly into each child it recognizes, so the contract is visible in the child's own prop types rather than hidden behind a context read.

  function Select({ children, value, onChange }: SelectProps) {
    const items = Children.map(children, (child) => {
      if (!isValidElement<OptionProps>(child)) return child;
      return cloneElement(child, {
        selected: child.props.value === value,
        onSelect: () => onChange(child.props.value),
      });
    });
    return <div role="listbox">{items}</div>;
  }
  

• Trade-off: cloneElement breaks if a consumer wraps an option in their own <div> or fragment — the clone only reaches direct children, so nesting silently drops the injected props. Context has no such restriction; any descendant, however deeply wrapped, can call useSelectContext(). Prefer Context for any compound API you expect consumers to wrap or rearrange; reserve cloneElement for sealed, internal component sets where you control every usage site.
• Build a flexible API by making the parent tolerant of missing, reordered, or extra children — derive an index from Children.toArray instead of relying on prop-based IDs, so consumers can omit an item conditionally without renumbering the rest.

  const orderedIds = Children.toArray(children)
    .filter(isValidElement<OptionProps>)
    .map((child) => child.props.value);
  // Safe even if a caller does {showCanada && <Select.Option value="ca" />}
  

• Export a discriminated union of sub-component prop types from the same module as the parent, so Select.Option usage outside <Select> is rejected by both the runtime guard and the type checker before the code ever ships.

The Container/Presentational pattern separates data-fetching logic from pure rendering. The container handles side effects, state, and API calls; the presentational component is a pure function of props with no side effects, making it trivially unit-testable and reusable across different data sources.

// Container: owns data fetching and state
function UserListContainer() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/users')
      .then((r) => r.json())
      .then((data) => { setUsers(data); setLoading(false); });
  }, []);

  if (loading) return <p>Loading...</p>;
  return <UserList users={users} />;
}

// Presentational: pure UI, no side effects
function UserList({ users }) {
  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

• Container components are responsible for what data is shown; presentational components control how it looks.
• Presentational components are easy to test with hardcoded prop data — no mocking required.
• In a hooks world, the container is often a custom hook (useUserList) rather than a wrapper component, but the separation of concerns stays the same.
• Useful for Storybook: presentational components can be developed and documented with mock props independent of any API.