cf5603243c
- 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)
71 lines
4.3 KiB
Markdown
71 lines
4.3 KiB
Markdown
# Research — 030-navbar-topo-ux
|
|
|
|
## Decision 1: Manter uma única Navbar compartilhada por todo o produto
|
|
|
|
**Decision**: Evoluir o componente compartilhado `frontend/src/components/Navbar.tsx` em vez de criar navbars separadas para visitante, cliente e admin.
|
|
|
|
**Rationale**: A navbar já é consumida por páginas públicas e layouts protegidos. Um único ponto de evolução reduz divergência visual, evita duplicação de links/rotas e facilita garantir consistência de comportamento entre desktop e mobile.
|
|
|
|
**Alternatives considered**:
|
|
- Criar três variantes independentes de navbar: rejeitado por elevar custo de manutenção e risco de regressões cruzadas.
|
|
- Extrair uma navbar diferente para admin: rejeitado nesta fase porque a spec pede eficiência sem poluir a experiência global, não uma shell totalmente nova.
|
|
|
|
---
|
|
|
|
## Decision 2: Consolidar o estado transitório em um único controlador de overlay
|
|
|
|
**Decision**: Planejar a navbar com um estado mutuamente exclusivo para `closed`, `mobile`, `client` e `admin`, mesmo que a implementação inicial parta do componente atual com múltiplos booleans.
|
|
|
|
**Rationale**: Os requisitos FR-011, FR-012 e FR-013 pedem previsibilidade forte. Um controlador único reduz a chance de estados simultâneos, simplifica o fechamento em mudança de rota e deixa o comportamento mais testável.
|
|
|
|
**Alternatives considered**:
|
|
- Manter três `useState` independentes: rejeitado como forma final porque exige disciplina manual em todos os handlers.
|
|
- Levar o estado para contexto global: rejeitado por excesso de complexidade para uma concern local de UI.
|
|
|
|
---
|
|
|
|
## Decision 3: Não introduzir novos contratos de API nem mudanças backend
|
|
|
|
**Decision**: Tratar a feature como frontend/UX puro, apoiada apenas pelos dados já disponíveis em `AuthContext` e nas rotas existentes em `App.tsx`.
|
|
|
|
**Rationale**: A spec descreve comportamento e hierarquia visual, não novos fluxos de domínio. `user`, `role`, `isAuthenticated` e `logout()` já cobrem as condições necessárias para as três personas.
|
|
|
|
**Alternatives considered**:
|
|
- Criar endpoint específico para navegação por perfil: rejeitado por desnecessário e contrário ao princípio de simplicidade.
|
|
- Mover a configuração de menu para backend: rejeitado nesta fase por não haver requisito de CMS/configuração dinâmica.
|
|
|
|
---
|
|
|
|
## Decision 4: Derivar destinos do menu a partir das rotas reais existentes
|
|
|
|
**Decision**: Basear o contrato de navegação nos destinos já disponíveis em `frontend/src/App.tsx` e na lista atual de módulos administrativos/cliente.
|
|
|
|
**Rationale**: Isso evita planejar links inexistentes e mantém a feature ancorada no sistema real. Também permite priorizar atalhos admin sem inventar módulos novos.
|
|
|
|
**Alternatives considered**:
|
|
- Redesenhar a informação da navbar a partir de destinos hipotéticos: rejeitado por abrir escopo além da spec.
|
|
- Remover rotas admin do topo nesta fase: rejeitado porque a spec exige acesso rápido para administradores.
|
|
|
|
---
|
|
|
|
## Decision 5: Formalizar um contrato de UI da navbar
|
|
|
|
**Decision**: Criar um documento em `contracts/navbar-ui-contract.md` descrevendo comportamento por perfil, breakpoint e estado interativo.
|
|
|
|
**Rationale**: Embora não exista API nova, a aplicação expõe uma interface de navegação para o usuário final. O contrato de UI serve como referência objetiva para implementação, QA e futura geração de tarefas.
|
|
|
|
**Alternatives considered**:
|
|
- Não criar contrato algum: rejeitado porque a feature é centrada em interação e estados, e isso precisa de definição explícita.
|
|
- Modelar o contrato só dentro do plan: rejeitado para manter separação clara entre abordagem técnica e comportamento esperado.
|
|
|
|
---
|
|
|
|
## Decision 6: Validar principalmente com build e checklist manual responsivo
|
|
|
|
**Decision**: Adotar `npm run build` como validação executável mínima e complementar com checklist manual por persona e breakpoint.
|
|
|
|
**Rationale**: O frontend atual não expõe uma suíte automatizada de testes de componentes/RTL. A natureza visual/interativa da navbar exige inspeção manual em desktop/mobile além da checagem de compilação.
|
|
|
|
**Alternatives considered**:
|
|
- Introduzir Vitest/RTL apenas para esta feature: rejeitado nesta fase de planning por ampliar escopo e dependências.
|
|
- Confiar só em validação visual manual: rejeitado porque o build ainda é o guardrail executável mínimo disponível.
|