Finoo Admin - Módulos de Partners, Users e Dashboard em Vue 3

Resumo

• Entrega: módulos de Partners, Users e Dashboard com telas completas para operação interna (listagem, detalhe e criação).
• Escalabilidade: consolidei a camada de dados e padronizei server-state (cache, invalidação, loading/erro) para manter comportamento previsível por módulo.
• Reuso: fortalecei componentes compartilhados (tabelas e padrões de formulário) para reduzir “feature spaghetti”.

Em ~3 meses, fui responsável por evoluir um painel administrativo (SPA) em Vue 3 + Vite + TypeScript, destravando rotinas internas com UX consistente e uma base técnica que permite continuar entregando módulos com menos retrabalho.

Contexto

• O projeto é um admin web para rotinas internas: gestão de usuários/parceiros e visão geral com KPIs e gráficos.
• A aplicação consome uma REST API interna e usa autenticação baseada em token (JWT via backend).
• No período analisado, não havia um setup claro de testes automatizados e pipeline de CI “as code”, então eu reduzi risco com tipagem, padrões de componentes e disciplina de revisão.

Principais desafios

• Escalar CRUD real (tabelas, filtros, estados vazios/loading, modais e formulários) sem virar código difícil de manter.
• Confiabilidade de dados em múltiplos recursos (cache, invalidação, paginação e tipagem) sem inconsistências entre telas.
• Visualização de dados: transformar respostas da API em gráficos úteis e legíveis, sem distorcer a leitura dos números.
• Operar sem testes: manter velocidade e reduzir regressões com TypeScript, estrutura da camada de dados e componentes compartilhados.

O que eu fiz

• Partners (gestão de parceiros)

  • Estruturei telas e componentes de listagem/criação/detalhes, incluindo formulários e seções de detalhes (ex.: dados legais, bancários e saldo).

• Users (gestão de usuários)

  • Evoluí a camada de dados (integração com API + tipagem) e conectei com UI de listagem/detalhe para reduzir fricção operacional.

• Dashboard (KPIs e gráficos)

  • Evoluí a home com KPIs e gráficos, cuidando de estados (loading/empty/error) e da transformação de dados para visualização.

• UI Core (componentes compartilhados)

  • Contribuí em componentes base de alto impacto (padrões de tabela e formulário) para aumentar consistência, reuso e previsibilidade entre módulos.

Decisões & trade-offs

• Server-state por recurso > store global para tudo

  • Por quê: padroniza cache/invalidação e estados (loading/error) por feature, com menos acoplamento entre telas.
  • Trade-off: exige convenções claras para evitar inconsistências e invalidations difíceis de rastrear.

• UI headless + composição > componentes prontos engessados

  • Por quê: flexibilidade para montar tabelas/forms/modais do admin com boa acessibilidade e consistência visual.
  • Trade-off: maior responsabilidade em manter padrões, principalmente em tabelas e flows de formulário.

• Exemplo específico (reduzindo regressão sem testes)

  • Padronizei convenções de cache e atualização de dados por módulo (listagens vs detalhes) e garanti estados consistentes no componente de tabela (loading/erro/empty) para evitar telas “meio quebradas” em edge cases.

Resultados

• Medido (engenharia): 82 commits atribuídos a mim (~39% do repo), com atuação concentrada em Partners/Users/Dashboard e UI compartilhada.
• Proxy técnico (concreto):
  • 3 módulos implementados com fluxos operacionais completos (listagem/detalhe/criação).
  • Camada de dados e tipagem ampliadas para suportar múltiplos recursos com menos repetição.
  • Dashboard evoluído com KPIs e gráficos, incluindo transformação de dados e estados previsíveis na UI.
• Operacional: o admin passou a suportar rotinas internas com menos “workarounds” fora do produto (planilhas, pedidos pontuais), aumentando previsibilidade do dia a dia.

Nota: métricas de produto (tempo economizado, redução de tickets, eficiência) não estavam disponíveis publicamente; evidências redigidas podem ser organizadas sob solicitação.

O que eu faria diferente

• Adicionar testes e CI mínimo: smoke de build/type-check + lint em PR, e testes de componente para tabelas/forms mais críticos.
• Documentar convenções de dados: padrões de cache/invalidação/paginação para escalar contribuições com consistência.
• Observabilidade no frontend: baseline de erros e eventos essenciais para identificar pontos de falha e gargalos operacionais do admin.