Nao perder formulario no app: descarte, volta e saida segura no React Native

Depois que um app ganha formularios mais longos, o problema deixa de ser apenas validacao. O problema vira perda de contexto. A pessoa volta sem querer, troca de rota, faz gesto de swipe, aperta o back do Android ou fecha o app no meio da tarefa e descobre tarde demais que o progresso foi embora. Em sistema corporativo, isso nao e detalhe de UX. E custo operacional.

O erro mais comum nessa fase e tentar resolver tudo com uma unica tecnica. Alguns times bloqueiam toda saida da tela e deixam a navegacao irritante. Outros nao bloqueiam nada e apostam que a pessoa vai lembrar de salvar. A documentacao oficial do React Navigation sugere um caminho mais maduro: usar protecao de saida com parcimonia e, quando possivel, persistir dado nao salvo para restauracao posterior.

Este guia organiza como pensar descarte, saida segura, botao voltar, gesto, fechamento do app e restauracao de rascunho no React Native.

1. Confirmar descarte e diferente de persistir rascunho

Essas duas coisas se complementam, mas nao sao equivalentes. Confirmar descarte protege o momento imediato em que a pessoa tenta sair. Persistir rascunho protege o trabalho quando a saida acontece de qualquer forma, quando o app fecha inesperadamente ou quando a pessoa decide voltar depois.

O artigo formulario multi-etapa com rascunho e retomada ja mostrou por que checkpoint e restauracao importam tanto. Aqui o foco e a camada de protecao de navegacao: quando interromper, quando confirmar e quando simplesmente deixar sair porque o rascunho ja esta protegido.

2. usePreventRemove foi feito exatamente para proteger saida de tela

A documentacao oficial do React Navigation descreve usePreventRemove de forma direta: o hook permite impedir que a pessoa saia de uma screen. O caso de exemplo e justamente mudanca nao salva. O hook recebe um booleano dizendo se a remocao deve ser evitada e um callback para abrir a confirmacao. O callback recebe a acao que tentou remover a rota, e essa mesma acao pode ser disparada de novo depois da confirmacao.

Esse desenho e melhor do que sobrescrever um botao isolado porque protege a screen contra varias formas de remocao de rota sem espalhar regra em cada gesto ou CTA de navegacao.

3. A pagina de preventing going back explica por que esse hook e melhor

O guia oficial de preventing going back do React Navigation compara a abordagem antiga com o hook novo. Antes, era comum sobrescrever o botao do header, desabilitar gesto de voltar e tratar o back do Android manualmente. O proprio guia explica por que usePreventRemove melhora isso:

• nao fica acoplado a um botao especifico;
• qualquer acao que remove a rota tambem dispara a protecao;
• funciona em navegadores aninhados;
• o swipe back pode acontecer, mas sera cancelado se o evento for prevenido;
• e possivel continuar exatamente a mesma acao depois da confirmacao.

Em app real, isso reduz a chance de proteger um caminho e esquecer outro.

4. Mas o proprio React Navigation tambem mostra os limites

A mesma documentacao do usePreventRemove faz questao de listar limitacoes importantes. O hook so roda quando a screen esta sendo removida por uma mudanca no estado de navegacao. Ele cobre casos como back em stack, swipe-back e acoes como pop e reset. Mas nao cobre tudo.

O texto oficial destaca que ele nao impede apenas unfocus quando a tela continua no estado, como ao empilhar outra screen por cima ou trocar de aba. Tambem nao impede saida do app por acoes fora do controle da navegacao, como fechar o aplicativo ou sair pelo app switcher.

Ou seja: usar o hook nao elimina a necessidade de rascunho local. Ele protege bem a remocao da rota. Nao protege sozinho o resto do mundo.

5. A propria documentacao recomenda usar o bloqueio com parcimonia

Esse ponto e especialmente valioso. Na secao de UX considerations, o React Navigation recomenda usar usePreventRemove com parcimonia. O texto vai alem: diz que uma abordagem melhor costuma ser persistir o dado nao salvo em AsyncStorage ou armazenamento semelhante e oferecer restauracao quando a pessoa voltar para a screen.

O motivo e simples e muito pratico:

• a solucao continua funcionando mesmo se o app fechar ou crashar;
• a experiencia fica menos intrusiva porque a pessoa consegue navegar, consultar algo e voltar sem perder o progresso.

Esse trecho encaixa perfeitamente com a linha editorial que estamos construindo: protecao de saida sim, mas sempre junto de estrategia de rascunho quando o fluxo merece.

6. Alert entra como mecanismo simples de confirmacao

O exemplo oficial de usePreventRemove para plataformas nao web usa Alert.alert para perguntar se a pessoa quer descartar as alteracoes. A documentacao de Alert mostra a assinatura do metodo com titulo, mensagem, botoes e opcoes. Ela tambem explica um detalhe do Android: o alerta pode ser tornavel cancelavel tocando fora, mas isso nao e o padrao.

Para confirmacao de descarte, o mais importante e manter intencao clara:

• um botao para continuar na tela;
• um botao destrutivo para descartar;
• linguagem curta e inequivoca sobre o que sera perdido.

Alerta aqui nao serve para dramatizar. Serve para evitar saida acidental quando ainda nao existe rascunho seguro ou quando o envio esta em andamento.

7. Fechar o app no Android pede BackHandler

O guia de preventing going back tambem mostra outro caso: impedir a pessoa de sair do app diretamente no Android usando BackHandler. A documentacao oficial do React Native para BackHandler explica o padrao de hardwareBackPress, deixando claro que, quando o handler retorna true, o evento nao sobe para outras acoes de back; quando retorna false, o comportamento padrao continua.

Isso ajuda em fluxos muito sensiveis, mas tambem pede criterio. Tratar o back do Android em toda tela pode virar uma guerra contra o sistema. Em geral, essa protecao faz mais sentido em telas em que sair do app realmente descartaria algo importante que ainda nao esta salvo.

8. Sair da tela, trocar de aba e empilhar nova rota nao sao o mesmo evento

Esse e um dos motivos de tanto erro de implementacao. A documentacao do usePreventRemove diferencia bem remocao da rota de simples unfocus. Se a pessoa navega para outra tab e a tela continua montada, o hook nao entra. Se outra rota e empilhada por cima sem remover a atual, tambem nao.

Por isso, o app precisa decidir o que faz quando a pessoa so sai do foco momentaneamente:

• manter o estado em memoria e pronto para retorno rapido;
• salvar checkpoint ao perder foco ou ao ir para background;
• mostrar aviso apenas quando houver remocao real da rota.

Confundir esses cenarios costuma gerar confirmacao em excesso ou perda silenciosa de progresso.

9. Formulario sujo nao significa bloquear tudo

Nem toda alteracao merece a mesma friccao. Campo editado por acidente, filtro temporario e fluxo longo de negocio nao pedem a mesma resposta. O criterio mais util costuma combinar impacto e recuperabilidade:

• se o dado e facilmente restauravel, priorize rascunho e reduza bloqueio;
• se a perda e cara e ainda nao existe checkpoint, confirme descarte;
• se o submit ja concluiu, limpe o estado e pare de bloquear a saida.

Esse raciocinio conversa direto com formularios com React Hook Form e Zod e com rascunho e retomada. A melhor UX aqui nasce da combinacao das pecas, nao do bloqueio isolado.

10. O aviso de descarte precisa acompanhar a arquitetura do fluxo

Fluxo simples de uma unica tela pode confirmar na saida e pronto. Mas formulario operacional com varias etapas costuma pedir uma estrategia mais organizada:

• salvar checkpoint ao concluir etapa;
• restaurar o rascunho se a pessoa voltar depois;
• confirmar descarte apenas quando ainda houver diferenca relevante nao persistida;
• limpar rascunho e desligar protecoes depois do envio confirmado.

Sem isso, a equipe cai em dois extremos ruins: ou confirma tudo o tempo todo, ou deixa o fluxo exposto e torce para ninguem sair sem querer.

11. Um desenho simples que costuma funcionar bem

1. Persistir rascunho para tudo que nao pode ser perdido facilmente.
2. Usar usePreventRemove apenas quando a rota esta realmente em risco de ser descartada com dado relevante nao salvo.
3. Usar Alert.alert para confirmacao curta e clara.
4. Usar BackHandler apenas em casos pontuais de saida do app no Android.
5. Diferenciar remocao da rota de simples unfocus.
6. Desligar a protecao depois do sucesso real do envio ou quando o rascunho ja estiver seguro.

12. Quando vale um diagnostico tecnico

Se o app hoje perde formulario por back acidental, dispara confirmacao em momentos errados, prende a pessoa em telas simples ou mistura bloqueio de rota com falta de rascunho, talvez o problema nao seja o hook isolado. Falta uma politica clara para perda de progresso. Nessa hora, um diagnostico tecnico ajuda a alinhar navegacao, persistencia local, UX de descarte e comportamento de submit antes que a experiencia fique hostil ou fragil.

Proteger formulario no mobile nao e brigar com a navegacao. E dar caminhos seguros para sair, voltar e retomar sem transformar cuidado em atrito desnecessario.

Referencias editoriais: React Navigation - usePreventRemove, React Navigation - Preventing going back, React Native - BackHandler e React Native - Alert.