Matheus/eden
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(client-registrations): reordena tela — Dados PJ, Sócios, Endereço, Contatos

Browse Source 
Ordem pedida pelo usuário. O <form> único virou dois (Sócios renderiza
seu próprio <form> interno entre eles, e form aninhado é inválido em
HTML) — ambos chamam o mesmo handleSubmit, que sempre lê o estado React
completo, então salvar continua gravando tudo de uma vez independente
de qual dos dois disparou. Testado ao vivo.

pnpm turbo run typecheck build: 28/28.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Matheus (Handix)
2026-09-18 13:30:35 -03:00
parent 93cd42b22e
commit 205d83a5f5
2 changed files with 147 additions and 121 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/progress.md
View File

@@ -720,3 +720,14 @@ Verificado: `pnpm turbo run typecheck build` 28/28, suíte 100/100 (95→100, 5
### Pendências
Lookup de CPF pra pessoa física — fora de escopo, não foi pedido. Refresh automático da situação cadastral/endereço (ex. um job periódico) não existe — "Buscar novamente" é manual, sob demanda.
---
## Reordenação do formulário de Cadastro de Cliente
Data: 2026-09-18. Usuário pediu: "primeiro vem os dados PJ depois vem os sócios depois endereço e depois contatos". Implementado diretamente (mudança de layout, sem lógica nova). Ordem final: Status (não mencionado, mantido primeiro) → Dados PF/PJ → Sócios (só PJ) → Endereço → Contatos → Portabilidade/botão de salvar (não mencionados, mantidos no final).
`ClientRegistrationDetailPage.tsx`: o `<form>` único virou dois — `PartnersSection` (Sócios) já renderiza seu próprio `<form>` interno (form aninhado é HTML inválido), então não dá pra intercalar sem quebrar essa regra. Os dois `<form>` chamam o mesmo `handleSubmit`, que sempre lê o estado React completo (`form`), nunca o DOM — testado ao vivo que salvar a partir do botão (agora depois de Contatos, no segundo `<form>`) grava corretamente campos da seção Status (primeiro `<form>`, antes de Sócios) junto com campos de Endereço (segundo `<form>`), confirmando que a divisão é só visual.
### Verificação
`pnpm turbo run typecheck build` 28/28. Suíte 100/100 (inalterada — mudança é só de frontend). Testado ao vivo em navegador real via Playwright: ordem das seções confirmada por leitura do DOM (`Status, Dados PJ, Sócios, Endereço, Contatos`) e por screenshot; ciclo completo com CNPJ real (Petrobras) mostrando os 10 sócios na nova posição; salvamento testado preenchendo um campo de cada `<form>` e confirmando após reload que os dois persistiram. Cadastro de teste desativado ao final.