Campos de Especialidade no Cadastro(front e backend)

[Austinmff]

Contexto

Os cadastros de paciente e profissional usam listas de especialidades hardcoded: o paciente busca de `/mocks/specialties.json` (17 itens), o profissional usa um array estático no componente (16 itens), e os filtros de busca têm um terceiro array com 6 itens. Não há consistência entre elas. O backend vai expor `GET /specialties` como source of truth (conectaBemBack#63).

Decisão de design

Criar um hook `useSpecialties()` que busca do endpoint `GET /specialties` e é compartilhado entre todos os pontos que usam lista de especialidades. Cachear com staleTime alto (especialidades mudam raramente). Regenerar tipos Kubb após o endpoint ser criado.

O que fazer

• Criar hook `useSpecialties()` que busca de `GET /specialties`
• Substituir `useGetSpecialty()` (que busca do mock) pelo novo hook no cadastro de paciente
• Substituir `specialtiesMock` no `SpecialtyStep.tsx` do profissional pelo novo hook
• Substituir `specializationOptions` em `MedicalSpecialization/options.ts` pelo novo hook (afeta Home e Search)
• Remover mock: `src/features/auth/mocks/specialties.json`
• Remover `specializationOptions` hardcoded
• Regenerar tipos Kubb (`npm run generate`)

Fora de escopo

• Criar o endpoint no backend (conectaBemBack#63 — pré-requisito)
• CRUD de especialidades
• Categorização de especialidades

Comportamento esperado

1. Cadastro de paciente exibe especialidades vindas da API
2. Cadastro de profissional exibe especialidades vindas da API
3. Filtros de busca (Home e Search) usam a mesma lista da API
4. Lista é cacheada no React Query

Critérios de aceite

• Hook `useSpecialties()` criado e reutilizável
• Cadastro de paciente usa especialidades da API
• Cadastro de profissional usa especialidades da API
• Filtros de busca usam especialidades da API
• Mocks e arrays hardcoded removidos
• Tipos Kubb regenerados

Stack / Restrições técnicas

React Query com staleTime alto (5min+). Endpoint público, não precisa de token.

Arquivos relevantes

• `src/features/auth/hooks/useGetSpecialty.ts`
• `src/features/auth/components/ProfissionalRegister/SpecialtyStep.tsx`
• `src/features/auth/components/PatientRegister/SpecialityStep/SpecialitiesSelection.tsx`
• `src/components/MedicalSpecialization/options.ts`

Dependências

• Pré-requisito: conectaBemBack#63 (endpoint GET /specialties)

📎Link da Task (Figma)

[PolyannaMeira]

@tarcisiopgs, finalizei a implementação da task conforme o escopo definido — as especialidades agora vêm da API em todos os pontos.

Antes de abrir o PR, notei que na página Home são exibidas todas as especialidades em linha (~20 itens). No Figma aparecem só 6. Podemos alinhar com o designer como resolver isso — um botão "Ver mais", um modal, ou outra abordagem?

Posso já subir o PR com o que está pronto e abrir uma nova issue para esse ajuste visual, ou prefere que eu aguarde e já inclua neste PR?

[tarcisiopgs]

Bem observado, @PolyannaMeira . Verifica se na API possui paginação. se sim, fazemos isso que você apresentou como proposta (botão ver mais requisitando as próximas páginas). caso não exista paginação na api, me informa que levantamos uma atividade pro pessoal preparar o backend.

[PolyannaMeira]

@tarcisiopgs, eu verifiquei e não tem paginação, a API retorna todas as especialidades de uma vez só.

[tarcisiopgs]

@PolyannaMeira boa! abri o developmentHC/conectaBemBack#78 cobrindo justamente esse gap. mudei o GET /specialties em dois pontos:

1. cada especialidade ganhou uma flag featured: boolean. comecei marcando 5 (acupuntura, aromaterapia, meditação, reiki, yoga) — alinha com o Figma que pede 6, fica fácil ajustar o set por diff se o designer pedir outro recorte.
2. o endpoint passa a aceitar ?featured=true (só destacados) e ?page=N (limite fixo 10, mesmo padrão dos outros endpoints). os dois combinam.

resposta mudou de array pro shape { specialties, page, pageCount }, igual aos searchProfessionalsHighlightsWeek que você já tá consumindo.

pra Home, recomendo useGetSpecialties({ featured: true }) no fallback — devolve as 5 seções de uma vez, sem precisar de "ver mais" porque cabe na primeira página. pra telas de cadastro e filtros, continua chamando sem param e usando o pageCount pra paginar se quiser.

depois que o PR do back fundir, roda npm run generate pro Kubb pegar o shape novo e os params, daí sobe seu PR. já testei o endpoint localmente contra o mongo, tá redondo.

[MateusFelS]

tudo certo