Componentes Personalizados

Distinguimos entre dois tipos de componentes personalizados, cada um com processos e expectativas diferentes.

Tipos de Componentes

A) Componentes Personalizados Específicos do Projeto

Componentes construídos para um projeto ou tela específicos, não destinados ao reuso em outros projetos.

Exemplos:

  • Um Caixa com layout especial usado dentro de um projeto

  • Um Card variante com layout personalizado para as telas de um projeto

  • Visualizações de dados específicas do projeto

  • Componentes de layout pontuais

Quando usar:

  • Componente resolve um problema único de um projeto

  • Pouco provável que seja necessário em outros projetos

  • Muito específico para generalizar

B) Componentes Candidatos a UI2

Componentes destinados ao reuso em múltiplos projetos e produtos.

Exemplos:

  • Navbar - Navegação em todo o site

  • UserMenu - Menu da conta do usuário

  • Padronizado Modal diálogos

  • Componentes sendo migrados do UI1

Quando usar:

  • Componente será usado em múltiplos projetos

  • Representa um padrão comum do Decentraland

  • Substitui ou estende um componente do UI1


Componentes Específicos do Projeto

Requisitos

Usar MUI como Base

DEVE estender componentes MUI existentes sempre que possível:

Não bifurque ou duplique padrões que o MUI já cobre:

  • Use Card em vez de criar uma caixa customizada com sombras

  • Use Button em vez de criar uma âncora estilizada

  • Use TextField em vez de criar um input personalizado

  • Estender Dialog em vez de criar um modal personalizado

Somente Valores do Tema

DEVE usar valores do tema UI2:

Nenhum valor arbitrário permitido:

  • Cores: Use theme.palette ou dclColors

  • Espaçamentos: Use theme.spacing(n)

  • Raio da borda: Use theme.shape.borderRadius

  • Tipografia: Use theme.typography variantes

  • Breakpoints: Use theme.breakpoints ajudantes

Estados e Acessibilidade

DEVE definir e implementar todos os estados interativos:

DEVE implementar acessibilidade básica:**

  • Navegação por teclado - Focável e operável com teclado

  • Indicadores de foco - Estados de foco visíveis

  • Labels ARIA - Onde o texto não é visível

  • HTML semântico - Usar elementos apropriados

  • Contraste de cor - Atendimento aos padrões WCAG AA

Exemplo: Componente Específico do Projeto


Componentes Candidatos a UI2

Componentes que serão compartilhados entre projetos requerem padrões mais elevados e documentação mais completa.

Requisitos

Alinhamento ao Tema

DEVE confiar exclusivamente nos valores do tema UI2:

Cobertura no Storybook

DEVE adicionar stories abrangentes no Storybook:

Cobertura obrigatória:

  1. Todas as props e variantes

    • Todas as combinações de props

    • Todas as variações de tamanho

    • Todas as variações de cor

  2. Todos os estados

    • Ocioso/padrão

    • Carregando

    • Erro

    • Desabilitado

    • Hover (via addon de pseudo estados)

    • Foco (via addon de pseudo estados)

  3. Interações

    • Manipuladores de clique

    • Envio de formulários

    • Navegação por teclado

  4. Esquemas de cor

    • Modo claro

    • Modo escuro

  5. Comportamento responsivo

    • Breakpoints chave (xs, md, lg)

    • Documentar comportamento em cada breakpoint

Arquivo de exemplo do Storybook:

Estrutura do Componente

Componentes candidatos a UI2 DEVEM seguir esta estrutura:

Requisitos de Documentação

DEVE incluir no README do componente:

  1. Propósito - Qual problema isso resolve?

  2. Uso - Como usar o componente

  3. Props - Todas as props com tipos e descrições

  4. Exemplos - Casos de uso comuns

  5. Acessibilidade - Suporte de teclado, labels ARIA

  6. Theming - Quais valores do tema ele usa

  7. Notas de migração - Se estiver substituindo um componente do UI1

Exemplo de README:

Requisitos de Testes

DEVE incluir testes para:

  • Renderização de props

  • Interações do usuário

  • Recursos de acessibilidade

  • Comportamento responsivo

  • Estados de erro


Matriz de Decisão

Use isto para decidir qual tipo de componente criar:

Pergunta
Específico do Projeto
Candidato a UI2

Outros projetos usarão isto?

Não

Sim

O UI1 tem um equivalente?

N/A

Provavelmente

Precisa de documentação no Storybook?

Não

Sim

Precisa de testes abrangentes?

Básico

Extensivo

Revisão de design necessária?

Nível do projeto

Nível UI2

Pode usar padrões específicos do projeto?

Sim

Não

Deve funcionar em todos os temas?

Não

Sim


Processo de Aprovação

Componentes Específicos do Projeto

  1. Revisão de código pelo mantenedor do projeto

  2. Verificar conformidade com o tema

  3. Testar no contexto do projeto

  4. Fazer merge quando aprovado

Componentes Candidatos a UI2

  1. Revisão e aprovação de design

  2. Revisão técnica de design

  3. Implementação

  4. Stories do Storybook

  5. Testes abrangentes

  6. Revisão de acessibilidade

  7. Revisão de código

  8. PR para o repositório UI2

  9. Versionar e publicar

  10. Atualizar projetos dependentes


Boas Práticas

Composição Sobre Customização

Aprimoramento Progressivo

Começar simples e adicionar recursos conforme necessário:

  1. Versão básica com funcionalidade central

  2. Adicionar comportamento responsivo

  3. Adicionar recursos de acessibilidade

  4. Adicionar interações avançadas

  5. Otimizar desempenho

Documentação Primeiro

Antes de escrever código:

  1. Escrever README do componente

  2. Definir a interface de props

  3. Listar estados necessários

  4. Planejar stories do Storybook

  5. Então implementar


Próximos Passos

Atualizado