Error boundaries y patrones avanzados — Routing, testing y patrones

Error Boundaries: capturar errores de render

Un error lanzado durante el renderizado de un componente desmonta, por defecto, toda la aplicación (pantalla en blanco). Un Error Boundary es un componente que captura los errores de su subárbol de hijos y muestra una interfaz de respaldo (fallback) en su lugar, en vez de tumbar la app entera.

Los error boundaries son uno de los pocos casos en los que todavía se usa un componente de clase, porque dependen de métodos de ciclo de vida que no tienen equivalente con hooks: getDerivedStateFromError y componentDidCatch:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hayError: false };
  }

  // Se llama cuando un hijo lanza al renderizar.
  // Devuelve el nuevo estado para mostrar el fallback.
  static getDerivedStateFromError() {
    return { hayError: true };
  }

  // Efecto secundario: aquí registrarías el error en un servicio de logging.
  componentDidCatch(error, info) {
    console.error(error, info);
  }

  render() {
    if (this.state.hayError) {
      return <h1>Algo salió mal.</h1>;
    }
    return this.props.children;
  }
}

// Uso: envuelve la parte que quieres proteger.
<ErrorBoundary>
  <Perfil />
</ErrorBoundary>;

Importante: los error boundaries no capturan errores en manejadores de eventos (un onClick que lanza), ni en código asíncrono, ni durante el renderizado en el servidor. Solo errores que ocurren durante el render de los componentes hijos.

Compound components

Los compound components (componentes compuestos) son un patrón para diseñar APIs flexibles y declarativas: un componente "padre" gestiona el estado y varios "hijos" colaboran con él, normalmente compartiendo datos por contexto. El usuario combina las piezas como si fueran etiquetas HTML relacionadas (<select> y <option>):

<Tabs>
  <Tab label="Inicio">Contenido de inicio</Tab>
  <Tab label="Ajustes">Contenido de ajustes</Tab>
</Tabs>

Tabs controla qué pestaña está activa; cada Tab se renderiza o no según ese estado compartido. La ventaja es una API expresiva y extensible: el que la usa decide qué pestañas hay y en qué orden, sin pasar largas listas de configuración por props.

Patrones históricos: render props y HOC

Antes de los hooks (React < 16.8), compartir lógica entre componentes se hacía con dos patrones que conviene reconocer al leer código antiguo:

Render props: un componente recibe una función como prop (a menudo la propia children) y le pasa datos para que decida qué pintar:
```
<RatonSeguidor>
  {({ x, y }) => <p>Cursor en {x}, {y}</p>}
</RatonSeguidor>
```
Higher-Order Component (HOC): una función que recibe un componente y devuelve otro con capacidades añadidas, como connect(...) de Redux clásico:
```
const ConDatos = withDatos(MiComponente);
```

Hoy, la mayoría de estos casos se resuelven de forma más simple con hooks personalizados, pero render props y HOC siguen apareciendo en librerías y bases de código existentes.