Componente Container/Presentation

Use esta habilidade para criar um componente React em src/components que siga o padrão Container/Presentation.

Consulte as referências incluídas nesta habilidade para obter regras detalhadas.

• references/component-architecture.md
• references/typescript-and-scss-rules.md

Se a entrada /react-container-presentation-component estiver incompleta, faça perguntas antes de criar arquivos.

Quando Usar

• Quando o usuário executar /react-container-presentation-component
• Quando o usuário solicitar explicitamente um componente React que siga o padrão Container/Presentation
• Quando o usuário quiser ajuda para decidir ou implementar a classificação ui vs features dentro do padrão Container/Presentation

Perguntas Necessárias

Se alguma das seguintes informações estiver faltando, pergunte ao usuário usando ask_user.

1. Nome do componente
2. Tipo (ui ou features)
3. Se deve substituir componentes existentes (apenas ao criar ui)

Requisitos das perguntas:

• Forneça o tipo como opções (ui, features)
• Exija que o nome do componente esteja em PascalCase
• Para ui, pergunte se o uso direto de Mantine ou outras bibliotecas de UI em features existentes deve ser substituído pelo novo componente

Procedimento

1. Verificar componentes existentes

• Verifique se src/components/ui/<ComponentName> ou src/components/features/<ComponentName> já existem.
• Se existir, não sobrescreva; confirme a abordagem preferida com o usuário.

2. Decidir diretório de destino

• ui: src/components/ui/<ComponentName>
• features: src/components/features/<ComponentName>

3. Re-verificar classificação (apenas quando ui for especificado)

• Mesmo quando ui for especificado, antes de criar arquivos, revise Reclassification Rule em references/component-architecture.md.
• Se a implementação incluir gerenciamento de estado, efeitos colaterais, processamento assíncrono, atualizações de contexto/store ou lógica de negócios, trate-a como features.
• Se o resultado for mais próximo de features, não prossiga como ui; use ask_user e confirme uma das seguintes opções antes de continuar.
  • Create as features
  • Keep ui and move state/logic to parent or features

4. Criar arquivos necessários

• ui: index.tsx, index.module.scss, index.stories.tsx
• features: index.tsx, use<ComponentName>.tsx, presentation.tsx, types.ts, presentation.module.scss, presentation.stories.tsx

5. Substituir usos existentes (apenas ao criar ui)

• Somente com a aprovação do usuário, substitua implementações diretas equivalentes usando Mantine ou outras bibliotecas de UI em features existentes pelo novo componente ui.

6. Validar

• Execute os comandos de build e lint e certifique-se de que ambos passem; se problemas forem introduzidos por arquivos recém-adicionados ou atualizados, corrija-os.
• Siga Storybook Minimum em references/component-architecture.md para decisões de estado do Story.
• Pergunte ao usuário via ask_user se deve executar uma verificação do Storybook (por exemplo: "Executar" / "Pular por enquanto").
• Execute npm run storybook somente se o usuário selecionar "Executar".
• Se o usuário selecionar "Pular por enquanto", mencione explicitamente no relatório final que a execução do Storybook foi pulada.

Contrato de Saída

• Relate a lista de arquivos criados.
• Se substituições foram realizadas, relate a lista de arquivos alterados e detalhes da substituição.
• Forneça um exemplo de uso do componente criado.
• Relate se a verificação do Storybook foi executada (executada/pulada) e, se executada, inclua o comando usado.
• Explique por que o componente foi classificado como ui ou features.
• Resuma onde o estado, os efeitos colaterais e as responsabilidades de renderização foram colocados.
• Confirme se houve alguma violação de direção de dependência.
• Declare claramente quaisquer itens não resolvidos.