- feat(025): favoritos locais com FavoritesContext, HeartButton, PublicFavoritesPage
- feat(026): central de contatos admin (leads/contatos unificados)
- feat(027): configuração da página de contato via admin
- feat(028): trabalhe conosco - candidaturas com upload e admin
- feat(029): UX área do cliente - visitas, comparação, perfil
- feat(030): navbar UX - menu mobile, ThemeToggle, useFavorites
- feat(031): hero light/dark - imagens separadas por tema, upload, preview, seed
- feat(032): performance homepage - Promise.all parallel fetches, sessionStorage cache,
preload hero image, loading=lazy nos cards, useInView hook, will-change carrossel,
keyframes em index.css, AgentsCarousel e HomeScrollScene via props
- fix: light mode HomeScrollScene - gradiente, cores de texto, scroll hint
migrations: g1h2i3j4k5l6 (source em leads), h1i2j3k4l5m6 (contact_config),
i1j2k3l4m5n6 (job_applications), j2k3l4m5n6o7 (hero theme images)
3.5 KiB
3.5 KiB
Quickstart — 030-navbar-topo-ux
Guia curto para implementar e validar a revisão UX/UI da navbar do topo.
Pré-requisitos
- Ambiente do projeto iniciado via
./start.ps1na raiz. - Frontend disponível em
http://localhost:5174. - Branch de trabalho:
030-navbar-topo-ux.
Credenciais úteis encontradas no frontend atual:
- Admin:
admin@demo.com/admin1234 - Usuário:
usuario@demo.com/demo1234
Superfícies de implementação
Arquivos com maior probabilidade de edição:
frontend/src/components/Navbar.tsxfrontend/src/contexts/AuthContext.tsxfrontend/src/index.css- Opcionalmente
frontend/src/layouts/ClientLayout.tsxefrontend/src/layouts/AdminLayout.tsxse houver ajuste fino de offset/spacing
Ordem recomendada de trabalho
1. Revisar a arquitetura local da navbar
- Mapear os grupos de links públicos, cliente e admin.
- Definir o modelo de estado único para overlays/contextos abertos.
- Garantir fechamento em clique fora, troca de rota e logout.
2. Ajustar a hierarquia visual desktop
- Reequilibrar logo, links primários, CTA e ações de conta.
- Limitar ruído visual e reforçar separação entre navegação pública e contextual.
- Validar truncamento do nome e destaque do CTA em ambos os temas.
3. Ajustar o comportamento mobile
- Garantir ordem lógica dos destinos no menu hambúrguer.
- Exibir seções
Minha ContaeAdminapenas para os perfis corretos. - Validar alvo de toque, foco e estados abertos/fechados.
4. Refinar logout e previsibilidade
- Conferir se logout fecha menus e retorna imediatamente ao estado visual de visitante.
- Se necessário, ajustar o comportamento atual de redirecionamento em
AuthContext.tsxpara evitar fricção visual desnecessária.
Validação executável
Na pasta frontend/:
npm run build
Esse é o guardrail mínimo obrigatório antes de concluir a implementação.
Checklist manual por persona
Visitante
- Desktop: links principais legíveis, CTA
Anunciar imóveldestacado e açãoEntrarvisível. - Mobile: hambúrguer abre e fecha corretamente, com os mesmos destinos públicos em ordem lógica.
- Tema claro/escuro: contraste suficiente em texto, hover e estado ativo.
Usuário autenticado
- Desktop: avatar/inicial, primeiro nome truncado e dropdown
Minha contafuncionam. - Dropdown:
Favoritos,Comparar,Visitas,Minha contaeSairfecham menu após clique. - Mobile: seção
Minha Contaaparece apenas quando autenticado não-admin.
Admin
- Desktop: gatilho
Adminvisível e separado da navegação pública. - Dropdown: atalhos admin navegam corretamente e fecham o menu.
- Mobile: seção
Adminaparece e não conflita com outros contextos.
Checklist de comportamento global
- Abrir dropdown admin fecha dropdown cliente.
- Abrir dropdown cliente fecha dropdown admin.
- Trocar de rota fecha menu mobile e dropdowns.
- Clique fora fecha o contexto aberto.
Tab,EntereEspaçofuncionam nos gatilhos relevantes.- Em 320 px, 768 px, 1024 px e 1280 px não há quebra ou sobreposição.
Risco conhecido para implementação
O comportamento atual de logout em AuthContext.tsx usa redirecionamento forçado para /login. Isso é funcional, mas pode entrar em tensão com o objetivo da spec de “retornar à navbar de visitante” com mínima fricção visual. A implementação deve decidir se mantém esse fluxo por regra de produto ou se o suaviza no frontend sem alterar segurança.