Error boundaries e padrões avançados — Routing, testes e padrões

Error Boundaries: capturar erros de render

Um erro lançado durante a renderização de um componente desmonta, por padrão, toda a aplicação (tela em branco). Um Error Boundary é um componente que captura os erros de sua subárvore de filhos e exibe uma interface de respaldo (fallback) em seu lugar, em vez de derrubar o app inteiro.

Os error boundaries são um dos poucos casos em que ainda se usa um componente de classe, porque dependem de métodos de ciclo de vida que não têm equivalente com hooks: getDerivedStateFromError e componentDidCatch:

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

  // Chamado quando um filho lança ao renderizar.
  // Retorna o novo estado para exibir o fallback.
  static getDerivedStateFromError() {
    return { temErro: true };
  }

  // Efeito colateral: aqui você registraria o erro em um serviço de logging.
  componentDidCatch(error, info) {
    console.error(error, info);
  }

  render() {
    if (this.state.temErro) {
      return <h1>Algo deu errado.</h1>;
    }
    return this.props.children;
  }
}

// Uso: envolva a parte que você quer proteger.
<ErrorBoundary>
  <Perfil />
</ErrorBoundary>;

Importante: os error boundaries não capturam erros em manipuladores de eventos (um onClick que lança), nem em código assíncrono, nem durante a renderização no servidor. Apenas erros que ocorrem durante o render dos componentes filhos.

Compound components

Os compound components (componentes compostos) são um padrão para projetar APIs flexíveis e declarativas: um componente "pai" gerencia o estado e vários "filhos" colaboram com ele, normalmente compartilhando dados por contexto. O usuário combina as peças como se fossem tags HTML relacionadas (<select> e <option>):

<Tabs>
  <Tab label="Início">Conteúdo de início</Tab>
  <Tab label="Configurações">Conteúdo de configurações</Tab>
</Tabs>

Tabs controla qual aba está ativa; cada Tab se renderiza ou não conforme esse estado compartilhado. A vantagem é uma API expressiva e extensível: quem a usa decide quais abas existem e em que ordem, sem passar longas listas de configuração por props.

Padrões históricos: render props e HOC

Antes dos hooks (React < 16.8), compartilhar lógica entre componentes era feito com dois padrões que convém reconhecer ao ler código antigo:

Render props: um componente recebe uma função como prop (muitas vezes o próprio children) e passa dados para que ele decida o que desenhar:
```
<SeguidorMouse>
  {({ x, y }) => <p>Cursor em {x}, {y}</p>}
</SeguidorMouse>
```
Higher-Order Component (HOC): uma função que recebe um componente e retorna outro com capacidades adicionais, como o connect(...) do Redux clássico:
```
const ComDados = comDados(MeuComponente);
```

Hoje, a maioria desses casos se resolve de forma mais simples com hooks personalizados, mas render props e HOC continuam aparecendo em bibliotecas e bases de código existentes.