Catch de erro do SWR

[filipedeschamps]

Contexto

Hoje tanto as páginas de conteúdo, quanto o ContentList e outros lugares, não lidam corretamente quando uma request retorna com erro por dentro do SWR, gerando um erro irrecuperável no client-side.

Execução

Identificar todos os pontos da aplicação que usam o SWR, por exemplo ao procurar por arquivos que contenham useSWR e caso o retorno da request contenha algum erro, sugiro apenas ignorar.

O SWR está sendo usado primariamente para revalidar o cache de um estático, então não deveria ter um grande impacto apenas ignorar o erro. Ou se quisermos ser mais arrojado, em casos que o statusCode de um response for 404 e a pessoa está numa página de conteúdo, redirecionar ela para a página https://www.tabnews.com.br/404

[Demnokkoyen]

Tenho interesse em trabalhar nessa issue e me pergunto se seria interessante extrair todas as requisições realizadas com o SWR em uma camada de serviços na arquitetura, possibilitando melhor manutenção quando for necessário realizar algum tipo de tratamento "global" direto na utilização da API (como é o caso aqui). O que acham? Posso seguir esse caminho e realizar essa refatoração?

[aprendendofelipe]

A biblioteca swr lida bem com erros de requisição. Então acredito que a motivação dessa issue são os erros que ocorrem quando a interface quebra ao receber novos dados, dependendo da mudança que ocorre com relação aos dados anteriores, ou seja, o problema é quando a requisição é sucesso, mas retorna dados diferentes e a interface não está preparada para lidar com a mudança recebida, indo para um estado inconsistente.

Parte do que quebrava a interface (ou tudo) foi corrigido a um tempo atrás quando o componente PublishedSince parou de dar erros com datas inválidas, caso que ocorria com conteúdos excluídos. Não sei se ainda existe alguma atualização de dados quebrando a interface. Mas aparentemente não.

Existem outras situações de atualização de dados que deixam a interface inconsistente e que são menos graves por não apresentar um erro irrecuperável. A maioria já foi corrigida anteriormente, mas ainda permanecem algumas relacionadas aos estados da página de conteúdos (issue #1376). Essas inconsistências só não estão tão aparentes porque o revalidateOnFocus está desativado atualmente.

Independentemente de ainda existir alguma questão que precisaria ser corrigida com o fetcher do swr, se o PR #1374 for aceito, isso não será mais problema, já que a partir daí a biblioteca só será utilizada para obter parte dos dados da página de status.

Os problemas específicos da página de conteúdos podem ser tratados na issue #1376, já que não são causados pelo swr.