Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
O Next.js 12 permitia escutar eventos de navegação com facilidade através do next/router, especialmente o evento routeChangeStart. Assim, era possível abrir um modal de confirmação ou cancelar a navegação antes dela acontecer.
No Next.js 13, com o novo app router, essa abordagem não funciona mais da mesma forma. A documentação sugere que a API mudou, dificultando a implementação de interceptações de navegação.
Mas e aí, como podemos garantir que o usuário não saia de uma página sem confirmação, especialmente em formulários ou processos críticos? Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
Algumas estratégias incluem:
beforeUnload do navegador, embora nem sempre seja ideal por questões de UX.Vocês já enfrentaram esse desafio? Como lidaram com a mudança na API do Next.js 13?
Vamos trocar experiências de soluções práticas para esse problema, especialmente pensando na experiência do usuário e na manutenção do código. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte.
E na parte de UX, não esquece de informar o usuário claramente. Nada de pop up que atrapalha, mas uma mensagem discreta que explica o porquê de confirmar a saída. Também vale definir quem revisa quando o fluxo sair do caminho feliz. O ganho fica mais claro quando existe rollback e métrica acompanhando.
O ponto do modal é essencial, mas cuidado com o impacto na performance se abusar de estados para cada navegação. Aqui, uma abordagem com um hook global que controla o fluxo pode ajudar.
Concordo, Thiago. O beforeUnload funciona bem pra alertar, mas nem sempre é a melhor experiência. O complicado é que o Next 13 não oferece uma solução nativa, então temos que pensar em algo mais robusto.
🤔
Será que essa mudança não força a gente a repensar toda a estratégia de navegação em apps em Next.js? Talvez usar mais rotas controladas e menos navegação automática? O ganho fica mais claro quando existe rollback e métrica acompanhando. Isso precisa aparecer no processo, não só na ferramenta. Eu validaria isso com um caso real antes de transformar em padrão. Esse detalhe muda bastante quando entra produção.