- clinica_id (tenant do scoreodonto, clinicas.id) como eixo de isolamento em clinics_devices e images (+índices); clinic_name vira rótulo legível. - Cadastro de device, socket (machine_token) e uploads (direct + legado) gravam clinica_id. - Listagens (/images, /patients, /by-patient, /unique-clinics) filtram por clinica_id. - /clients: lista clientes Windows ativos (inclui autenticados sem client-identify), tempo real + polling, exibe a clínica. - send-image marcado como legado (client real usa Direct Upload). Inclui trabalho de dev acumulado no working tree (não havia commits desde origin/main). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6.5 KiB
Contexto de Desenvolvimento e Melhorias Estéticas
Este documento serve como um mapa do estado atual do projeto, detalhando as diretrizes arquiteturais, o ambiente de desenvolvimento, e o que foi feito na nossa refatoração premium. O objetivo é manter o contexto intacto para continuarmos os trabalhos amanhã de onde paramos.
1. Contexto de Deploy e Desenvolvimento
Ambiente e Stack:
- Frontend: Vite + React (rodando no container
rx_dev_clientna porta 5173). - Backend: Node.js (Express) com Socket.io (rodando no container
rx_dev_apina porta 3000). - Banco de Dados: PostgreSQL (com proxies/cache via Redis/DragonflyDB).
- Infraestrutura: Docker Compose com persistência e mapeamento de portas (
network_mode: hostpara desenvolvimento).
Estabilidade e Otimizações Críticas Alcançadas:
- Fim do Loop de WebSocket: O backend estava travando em um loop infinito porque JWTs (que podiam conter hífens) estavam sendo tratados como UUIDs de
machine_tokenno login do Socket, crachando o Postgres. A regra foi substituída por uma RegEx estrita de UUID, estabilizando a API e o proxy do Vite. - Performance Extrema em
/patients: A listagem de pacientes executava múltiplas subqueries correlacionadas dentro de umGROUP BY, causando lentidão severa. A query foi reescrita utilizando CTE (WITH) e LEFT JOIN LATERAL do Postgres, reduzindo o tempo de resposta da rota de múltiplos segundos para cerca de 9 milissegundos. - Resolução de Quedas do WebSocket (O bug do "WebSocket is closed before the connection is established"):
- Diagnóstico: O erro era causado pelo
React StrictModeno ambiente de desenvolvimento, que executa ouseEffectduas vezes (monta, desmonta e remonta quase instantaneamente). Na primeira montagem, a conexão do Socket.IO era iniciada, mas o cleanup imediato a desconectava antes do handshake finalizar, lançando o erro no proxy do Vite e sujando o console. - Correção no Código: Implementamos um atraso inteligente (
setTimeout(150ms)) na criação do socket dentro deSocketContext.jsx. Dessa forma, o ciclo rápido do StrictMode cancela o timer antes da conexão sequer iniciar, subindo apenas a segunda conexão de forma estável. Em Produção, isso garante um delay imperceptível sem impacto negativo. - Esclarecimento de Infraestrutura (Traefik): O Traefik da VPS 1 lida com conexões WSS automaticamente por padrão. Falsas soluções, como forçar middlewares de injecção de cabeçalho (
Upgrade: websocket) nas rotas do Traefik, são prejudiciais pois injetam esse header em todas as requisições HTTP estáticas (ex:/favicon.icoou/), levando o Node/Express a rejeitá-las e causando erros502 Bad Gatewayno ambiente de produção. As configurações do Traefik voltaram ao estado padrão, já que a solução de código no React eliminou o problema raiz.
- Diagnóstico: O erro era causado pelo
2. Como as coisas estão sendo feitas (A Nova Diretriz)
A regra de ouro estabelecida para o UX/UI do projeto é:
"Esquece o sidebar (para aberturas dinâmicas), foque nas páginas. Vamos trocar modais empilhados por páginas dedicadas!"
Fluxo de Trabalho:
- Nenhuma ação complexa (como criar um paciente ou detalhar uma GTO) deve acontecer em um Modal apertado.
- Tudo agora utiliza rotas reais do
react-router-dom(ex:/gtos/new,/patients/:id), controladas pelo hookuseNavigate. - O código das listagens perdeu centenas de linhas inúteis e ficou puramente focado em listar, buscar e filtrar.
3. Estética Premium: Desktop vs Mobile
Estamos implementando uma estética "WOW" moderna, que transparece profissionalismo e luxo (vibrant colors, glassmorphism, micro-animações, sombras sutis).
💻 Para Desktop:
- Telas Imersivas (Full-page): Ao invés de um modal de 400px, a criação de itens abre uma página inteira. O formulário é apresentado dentro de um card central (
boxShadow: 0 4px 20px rgba(0,0,0,0.04)) com inputs largos e bem espaçados. - Navegação "Breadcrumb": Botões nativos estilizados com setas para voltar (
<I.arrowLeft />) e cabeçalhos (main-header) limpos. - Tipografia e Cores: O contraste foi ajustado para usar
var(--ink)para títulos de peso 800 evar(--muted)para legendas, entregando uma hierarquia visual sofisticada. - Tabelas Interativas: As linhas das tabelas agora possuem hover states sutis (
var(--surface-hover)) e botões de ação ("Acessar", "Editar") visíveis sem poluir o grid.
📱 Para Mobile / Responsivo:
- App-like Experience: O mobile não é apenas uma versão espremida do desktop; ele possui componentes dedicados (
.mob-screen,MobileUI). - Bottom Sheets & Drawers: Ações rápidas de revisão abrem em "Bottom Sheets" (
.sheet-in) que deslizam de baixo para cima, imitando a navegação nativa do iOS/Android. - Botões Flutuantes e Floating Actions: Botões de criar novo (
+) e pesquisar foram promovidos para o topo como botões estilo pílula (.pill-btn.lg), muito mais acessíveis para toques com os polegares. - Scroll Inteligente: Listagens no mobile usam Infinite Scroll escondendo o overflow horizontal, garantindo que o usuário só mova a tela para cima e para baixo.
4. Onde Paramos e Próximos Passos (Para Amanhã)
O que já está 100% migrado para a nova arquitetura de Páginas:
✅ GTOs: /gtos, /gtos/new, /gtos/:id
✅ Pacientes: /patients, /patients/new, /patients/:id
🎯 Foco para Amanhã (Acesso via API):
-
Sistema de Tokens / API:
- Melhorar a estética do painel de integrações.
- Criar um card premium "Zapier CRM" ao lado do botão de gerar token.
- Criar o botão mágico "Copiar Documentação Completa" — que, após gerar o nome da integração, ativa e copia todas as APIs de uma vez (economizando tempo de implementação em outros sistemas).
-
Endpoints e Sincronização:
- Criar paciente via App Client Windows (comunicação externa).
- Enviar sinal de sincronização.
- Criar acessos / clínicas via API.
- Listar pacientes e seus RXs.
- Listar GTOs e detalhamentos.
- Nota: Tudo isso será feito 100% via API documentada.
-
Continuação do UI (Desktop baseando-se no Mobile):
- Iniciar o processo inverso: pegar a estética que deu certo no Mobile/Responsivo e trazer melhorias para a versão Desktop.
- Primeiro alvo de UI: A página Galeria (conforme solicitado anteriormente).
- Migrar as demais páginas restantes (ex: Configurações, Usuários) removendo completamente a dependência de Modais, seguindo o padrão de rotas limpas inaugurado hoje.