{"componentChunkName":"component---src-templates-blog-js","path":"/blog/2017/07/26/error-handling-in-react-16.html","result":{"data":{"markdownRemark":{"html":"

Como a versão 16 do React está próxima, nós gostaríamos de anunciar algumas pequenas mudanças de como o React lida com os erros JavaScript dentro dos componentes. Estas mudanças foram incluidas na versão beta do React 16 e fará parte do React 16.

\n

A propósito, nós acabamos de lançar a primeira versão beta do React 16 para você testar!

\n

Funcionamento no React 15 e Antecessor

\n

Anteriormente, os erros JavaScript dentro dos componentes costumavam corromper o estado interno do React e fazer com que ele emita erros difíceis de entender nos próximos renderizadores. Estes erros foram sempre causados por erros antecessores no código da aplicação, mas o React não providenciava uma forma de manipulá-los de um modo elegante nos componentes, e não poderia se recuperar a partir deles.

\n

Introduzindo as Limitações de Erros

\n

Um erro JavaScript na parte da UI não deve parar toda a aplicação. Para resolver estes problemas para os usuário do React, o React 16 introduz um novo conceito de “limitação de erro”

\n

Limitações de erros são componentes React, que capturam os erros JavaScript em qualquer lugar referente à arvore de seus componentes filhos, registra os erros e mostra uma alterantiva de UI ao invés da árvore do componente que foi danificada. As limitações de erros capturam os erros durante a renderização, nos métodos de ciclo de vida e nos construtores de toda a árvore abaixo dele.

\n

Um componente de classe torna-se um limitador de erro, se ele definir um novo método do ciclo de vida, chamado componentDidCatch(error, info):

\n
class ErrorBoundary extends React.Component {\n  constructor(props) {\n    super(props);\n    this.state = { hasError: false };\n  }\n\n  componentDidCatch(error, info) {    // Mostra uma UI alternativa    this.setState({ hasError: true });    // Você também pode registrar o erro em um serviço de relatório de erros    logErrorToMyService(error, info);  }\n  render() {\n    if (this.state.hasError) {      // Você pode renderizar qualquer alternativa de UI      return <h1>Algo deu errado.</h1>;    }    return this.props.children;\n  }\n}
\n

Então você pode usar ele como um componente comum:

\n
<ErrorBoundary>\n  <MyWidget />\n</ErrorBoundary>
\n

O método componentDidCatch() funciona como o block catch {} do JavaScript, porém, para componentes. Apenas componentes de classe podem ser limitadores de erros. Na prática, na maioria das vezes, você vai querer declarar um componente limitador de error apenas uma vez e usá-lo ao longo da sua aplicação.

\n

Observe que limitadores de erros, apenas conseguem capturar erros nos componentes abaixo deles na árvore. Um limitador de erro não consegue capturar um erro dentro de sí próprio. Se um limitador de erro falhar ao tentar renderizar a mensagem de erro, o erro irá propagar até o limitador de erro máis próximo, localizado acima dele. Este também é de modo similar, como o block catch {} funciona no JavaScript.

\n

Demonstração Ao Vivo

\n

Confira este exemplo de declaração e uso do limitador de erro com o React 16 beta.

\n

Onde Posicionar os Limitadores de Erros

\n

Os pequenos detalhes dos limitadores de erros depende de você. Você pode envolver componentes de rota (superior aos outros componentes) para mostrar uma mensagem, como “Algo deu errado” para o usuário, semelhante aos frameworks de lado do servidor, que geralmente lidam com os conflitos. Você também pode envolver widgets individualmente em um limitador de erro, para os proteger de colidirem com o resto da aplicação.

\n

Novo Comportamento para Erros Não Capturados

\n

Esta mudança tem uma consequência importante. A partir do React 16, os erros que não forem capturados pelos limitadores de erros, resultará no desmontamento completo da àrvore do componente React.

\n

Nós discutimos esta decisão, mas pela nossa experiência é pior deixar a UI corrompida ao invés de removê-la completamente. Por exemplo, em um produto como Messenger, deixar uma UI corrompida visível pode levar alguém a enviar uma mensagem para uma pessoa errada. De forma similar, é pior para um app de pagamento mostrar uma quantia errada do que renderizar nada.

\n

Esta mudança significa que à medida que você migra para o React 16, você provavelmente descobrirá falhas existentes na sua aplicação que não foram percebidas anteriormente. Adicionar limitadores de erros permite você prover uma melhor experiência de usuário quando algo dá errado.

\n

Por exemplo, o Facebook Messenger envolve o conteúdo da barra lateral, o painel de informações, o log de conversação e o campo de entrada da mensagem dentro de limitadores de erros separados. Se algum componente de uma dessas áreas da UI falharem, o resto deles permanecem interativo.

\n

Nós também incentivamos você a usar serviços de relatórios de erros JS (ou construir o seu próprio), de modo que você possa aprender sobre exceções não tratadas conforme elas acontecem em produção e corrigi-las.

\n

Rastros da Pilha do Componente

\n

O React 16 exibe todos os erros que ocorreram durante a renderização de desenvolvimento no console, mesmo se a aplicação acidentalmente tenha os aceitado. Além da mensagen de erro e da pilha JavaScript, também é fornecido os rastros da pilha do componente. Agora você pode ver exatamente onde na àrvode do componente a falha ocorreu:

\n\n \n \n \n \n \"Rastros\n \n \n \n \n \n

Você também consegue ver os nomes dos arquivos e os números das linhas no rastro da pilha do componente. Isto funciona por padrão nos projetos Create React App:

\n\n \n \n \n \n \"Rastro\n \n \n \n \n \n

Se você não usa o Create React App, você pode adicionar este plugin manualmente as configurações do seu Babel. Observe que isto destina-se apenas para desenvolvimento e deve ser desativado em produção.

\n

Por que não usar try / catch?

\n

try / catch é ótimo, mas funciona apenas para código imperativo:

\n
try {\n  showButton();\n} catch (error) {\n  // ...\n}
\n

Porém, componentes React são declarativos e especificam o que deve ser renderizado:

\n
<Button />
\n

Limitadores de erros preservam a natureza declarativa do React, e se comportam como você esperaria. Por exemplo, mesmo se um erro ocorresse no método componentDidUpdate, causado por um setState em algum lugar profundo da árvore, ainda assim irá propagar corretamente para o limitador de erro mais próximo.

\n

Mudanças de Nomenclatura do React 15

\n

O React 15 incluiu um suporte muito restrito aos limitadores de erros utilizando um nome de método diferente: unstable_handleError. Este método não funciona mais, e você precisará trocar em seu código para componentDidCatch a partir da primeira versão beta 16.

\n

Para esta mudança, nós fornecemos uma ferramenta de refatoração para migrar seu código automaticamente.

","excerpt":"Como a versão 16 do React está próxima, nós gostaríamos de anunciar algumas pequenas mudanças de como o React lida com os erros JavaScript dentro dos componentes. Estas mudanças foram incluidas na versão beta do React 16 e fará parte do React 16. A propósito, nós acabamos de lançar a primeira versão beta do React 16 para você testar! Funcionamento no React 15 e Antecessor Anteriormente, os erros JavaScript dentro dos componentes costumavam corromper o estado interno do React e fazer com que…","frontmatter":{"title":"Tratamento de Erro no React 16","next":null,"prev":null,"author":[{"frontmatter":{"name":"Dan Abramov","url":"https://twitter.com/dan_abramov"}}]},"fields":{"date":"26 de julho de 2017","path":"content/blog/2017-07-26-error-handling-in-react-16.md","slug":"/blog/2017/07/26/error-handling-in-react-16.html"}},"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"React v17.0"},"fields":{"slug":"/blog/2020/10/20/react-v17.html"}}},{"node":{"frontmatter":{"title":"Apresentando o novo JSX Transform"},"fields":{"slug":"/blog/2020/09/22/introducing-the-new-jsx-transform.html"}}},{"node":{"frontmatter":{"title":"React v17.0 Candidato à lançamento: Sem novas funcionalidades"},"fields":{"slug":"/blog/2020/08/10/react-v17-rc.html"}}},{"node":{"frontmatter":{"title":"React v16.13.0"},"fields":{"slug":"/blog/2020/02/26/react-v16.13.0.html"}}},{"node":{"frontmatter":{"title":"Construindo Ótimas Experiências de Usuário com Modo Concorrente e Suspense"},"fields":{"slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}}},{"node":{"frontmatter":{"title":"Preparando para o Futuro com as Prereleases React"},"fields":{"slug":"/blog/2019/10/22/react-release-channels.html"}}},{"node":{"frontmatter":{"title":"Apresentando o novo React DevTools"},"fields":{"slug":"/blog/2019/08/15/new-react-devtools.html"}}},{"node":{"frontmatter":{"title":"React v16.9.0 e a atualização do Roadmap"},"fields":{"slug":"/blog/2019/08/08/react-v16.9.0.html"}}},{"node":{"frontmatter":{"title":"O React já esta traduzido? ¡Sí! Sim! はい！"},"fields":{"slug":"/blog/2019/02/23/is-react-translated-yet.html"}}},{"node":{"frontmatter":{"title":"React v16.8: O React com Hooks"},"fields":{"slug":"/blog/2019/02/06/react-v16.8.0.html"}}}]}},"pageContext":{"slug":"/blog/2017/07/26/error-handling-in-react-16.html"}},"staticQueryHashes":[]}