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

feat(resellers): UI de CNPJ/sócios/endereço/contatos, na ordem certa

Browse Source 
Mesma UI construída pro Cadastro de Cliente, aplicada a Revenda, já
direto na ordem pedida (Dados -> Sócios -> Endereço -> Contatos), sem
precisar de uma segunda leva de reordenação. Criar uma revenda agora
redireciona pra edição dela (não pra lista) já que CNPJ-lookup/Sócios
só fazem sentido com um id existente. PartnersSection generalizada
para reuso entre Cliente e Revenda.

Corrige um bug real encontrado na verificação ao vivo: o rótulo do
botão de busca estava amarrado ao que estava sendo digitado, não ao
que já foi salvo — digitar um CNPJ válido trocava pra "Buscar
novamente" antes de qualquer busca real acontecer.

Suíte: 106/106 (inalterada). pnpm turbo run typecheck build: 28/28.
Testado ao vivo com CNPJ real (Petrobras).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Matheus (Handix)
2026-09-18 15:18:34 -03:00
parent 2ae61dba22
commit ec13dccee6
5 changed files with 943 additions and 46 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/progress.md
View File

@@ -762,3 +762,16 @@ Endpoints novos em `resellers.controller.ts`: `GET/POST /v1/resellers/:id/partne
### Pendências
UI ainda não construída — só o backend nesta leva (frontend é o próximo passo natural, mesmo padrão de Cliente: Dados PJ → Sócios → Endereço → Contatos, já direto na ordem certa desta vez, sem precisar de uma segunda leva de reordenação).
---
## UI de Cadastro de Revenda — CNPJ, sócios, endereço, contatos
Data: 2026-09-18. Frontend da leva anterior (agente `eden-frontend`), construído direto na ordem pedida: Dados da revenda (com busca de CNPJ) → Sócios → Endereço → Contatos → Status.
`ResellerFormPage.tsx` reescrita: ao criar uma revenda nova (sem `id` ainda), continua só com os campos mínimos (Nome/Documento/E-mail/Ativo) — CNPJ-lookup e Sócios precisam de um `id` existente. Diferença de UX deliberada em relação a Cliente: depois de criar, o usuário é redirecionado direto pra `/resellers/:id/edit` (antes voltava pra lista) — senão não teria como usar as novidades sem um clique extra. `PartnersSection.tsx` foi generalizado (`apps/core-web/src/components/PartnersSection.tsx`, funções de API via prop) em vez de duplicado — a versão de Cliente ficou como estava, pronta pra migrar depois se fizer sentido, sem necessidade agora.
**Bug real encontrado e corrigido na verificação ao vivo (por mim, não pelo agente)**: o rótulo do botão ("Buscar CNPJ" vs. "Buscar novamente") estava amarrado à contagem de dígitos do campo `document` sendo DIGITADO (`form.document`, ainda não salvo) em vez de ao valor já persistido no servidor — resultado: digitar um CNPJ válido já trocava o botão para "Buscar novamente" antes de qualquer busca real ter acontecido, uma mensagem enganosa (funcionalmente a busca ainda funcionava, mas o texto mentia sobre o estado). Corrigido com um novo estado `savedDocument` (preenchido só a partir do que o servidor confirma — ao carregar, ao salvar manualmente, ao concluir uma busca), o rótulo agora reflete a persistência real, não a digitação.
### Verificação
`pnpm turbo run typecheck build` 28/28 (antes e depois da correção). Suíte 106/106 (inalterada, mudança de frontend). Testado ao vivo em navegador real via Playwright, incluindo o cenário exato do bug (digitar 14 dígitos antes de qualquer busca — botão permanece "Buscar CNPJ" corretamente agora) e o ciclo completo com CNPJ real (Petrobras, nome fantasia e sócio confirmados). Revendas de teste desativadas ao final.