{"id":1847,"date":"2017-11-06T17:22:35","date_gmt":"2017-11-06T20:22:35","guid":{"rendered":"http:\/\/www.milfont.org\/tech\/2017\/11\/06\/monitoramento-e-manipulacao-de-erros-no-pwa-com-react-e-redux\/"},"modified":"2017-11-06T17:22:35","modified_gmt":"2017-11-06T20:22:35","slug":"monitoramento-e-manipulacao-de-erros-no-pwa-com-react-e-redux","status":"publish","type":"post","link":"https:\/\/www.milfont.org\/tech\/2017\/11\/06\/monitoramento-e-manipulacao-de-erros-no-pwa-com-react-e-redux\/","title":{"rendered":"Monitoramento e manipula\u00e7\u00e3o de erros no PWA com React e Redux"},"content":{"rendered":"

Adendo: N\u00e3o sabe bem o que \u00e9 <\/em>PWA<\/em><\/strong>? <\/em>Leia o resumo<\/em><\/a>.<\/em><\/p>\n

Colocou a App em produ\u00e7\u00e3o? Vamos conversar.<\/h4>\n

Voc\u00ea n\u00e3o conseguir\u00e1 impedir erros em produ\u00e7\u00e3o e principalmente lidar com isso na intera\u00e7\u00e3o com o usu\u00e1rio mesmo que sua aplica\u00e7\u00e3o tenha uma cobertura de 100% com testes unit\u00e1rios, um bom ratio pra cada linha de c\u00f3digo e testes de aceita\u00e7\u00e3o\/integra\u00e7\u00e3o.<\/p>\n

\n

Voc\u00ea est\u00e1 errado em todas as metodologias se n\u00e3o testa de forma automatizada.<\/p>\n<\/blockquote>\n

Reagindo a erros n\u00e3o esperados<\/h4>\n

A vers\u00e3o 16 do React trouxe um m\u00e9todo excelente no ciclo de vida dos componentes, o componentDidCatch<\/strong><\/a>, que captura todas as exce\u00e7\u00f5es lan\u00e7adas pelos n\u00f3s abaixo na \u00e1rvore do componente que manipula esse m\u00e9todo.<\/p>\n

Em outras palavras, todo erro que acontecer abaixo de ErrorBoundary<\/em><\/strong> (ver c\u00f3digo seguinte) ser\u00e1 capturado num \u00fanico ponto sem a necessidade de espalhar try\/catch pelo c\u00f3digo de apresenta\u00e7\u00e3o.<\/p>\n

De qualquer forma, todas as transforma\u00e7\u00f5es de estado devem ser concentradas no redux como o c\u00f3digo a seguir.<\/p>\n

https:\/\/gist.github.com\/cmilfont\/e4fa20e1ced19a36fcdf948916184ade<\/a><\/p>\n

Independente de como mostrar a UI para o usu\u00e1rio ao acontecer um erro, essa informa\u00e7\u00e3o vir\u00e1 exclusivamente de um ponto que \u00e9 administrado por transa\u00e7\u00f5es das sagas.<\/p>\n

Estado Centralizado<\/h3>\n

Temos v\u00e1rios vantagens em centralizar a manipula\u00e7\u00e3o de erros no redux, a principal \u00e9 que podemos concentrar o monitoramento em um \u00fanico lugar com os dados trackeados pelo sua ferramenta, seja Airbreak, Logentries ou Sentry<\/a>.<\/p>\n

https:\/\/gist.github.com\/cmilfont\/a0009b8e0af3e4ce0eb1e23439324314<\/a><\/p>\n

Qual a diferen\u00e7a entre colocar um window.onError?<\/p>\n

Facilitar coordenar tipos de erros junto ao estado da aplica\u00e7\u00e3o, al\u00e9m de indicar um \u00fanico ponto de manuten\u00e7\u00e3o porque esses tipos precisam de transforma\u00e7\u00f5es e Tracking.<\/p>\n

Track dos\u00a0erros<\/h3>\n

Dado a centraliza\u00e7\u00e3o dos erros, agora partir para logar direto no seu servi\u00e7o que provavelmente tem dezenas de m\u00e9todos de notifica\u00e7\u00f5es e habilitar a integra\u00e7\u00e3o com seu Issue Tracking.<\/p>\n

\n


\n<\/figure>\n

\n

Tracking, notifica\u00e7\u00e3o e resolu\u00e7\u00e3o de\u00a0erros.<\/figcaption><\/figure>\n

Offline<\/h3>\n

O ecossistema Redux tamb\u00e9m agrega a vantagem de facilitar a persist\u00eancia dos erros para tracking e an\u00e1lise futura ou evitar a submiss\u00e3o constante de notifica\u00e7\u00f5es aproveitando para enviar em Batch num tempo determinado.<\/p>\n

Em alguns casos extremos, principalmente em integra\u00e7\u00e3o, voc\u00ea pode exportar o store na window para disparar um error que extrapola a aplica\u00e7\u00e3o com window.onError = error=> (window.store.dispatch({ type: ‘GLOBAL_ERROR’, payload: error }));<\/em><\/strong><\/p>\n

\n
\n

Unit tests: 100% coverage
Integration tests: n\/a pic.twitter.com\/ptMkXTXZSV<\/a><\/p>\n

— Daniel Martins (@danielfmt) August 2, 2017<\/a><\/p>\n<\/blockquote>\n