Estrutura Front-End: feature, lib e paridade de pastas

Domínio na pasta da feature, primitivos na lib, pontes só enquanto há consumidores, protótipo alinhado ao entregável.

Front-End

Que tipo de artigo é este? Estrutura que sobrevive ao handoff: onde mora o domínio, onde mora o primitivo, e como o protótipo não vira um segundo mapa mental.

Tese Feature = verdade de negócio. Lib = contrato visual. Ponte = temporária. Cruzar projects = dívida.

Arvore feature versus lib — Figura 1 — Row de tabela é domínio; Button é lib.

feature/
  components/   # row de tabela = dominio aqui
  services/     # mock atras do servico
  types/
  routes/

lib (@vds) /
  Button FormField Feedback Overlay tokens

Duas árvores, um contrato

Protótipo explora UX, mas a árvore de pastas deve espelhar o entregável. Migrar componente compartilhado: fase 1 = lib + alias + barrel; fase 2 = virar imports. Não apagar pontes enquanto ainda há consumidores.

Prototipo e entregavel alinhados — Figura 2 — Alinhar pastas; validar com print, não feeling.

Handoff checklist
[ ] mock no servico (nao na page)
[ ] tipos estaveis
[ ] zero cruzamento entre projects
[ ] pastas estaveis antes do DEV
[ ] primitivos so na lib
[ ] print de paridade no mesmo dia

Rotas mortas: se o aggregator não importa, é código morto — confirme antes de apagar.
Organizar um project modelo: mexer só nele + pontes; não virar o mundo.
Paridade visual = métrica (z-index, FILL, gap) lado a lado.

Duas árvores, um contrato

Continuar lendo