Modelo de maturidade de componentes

Pense que você é um programador, um programador front-end. Você colabora com o desenvolvimento de um produto web. Você trabalha junto com designers, programadores back-end e product owners. Então um belo dia numa reunião, numa apresentação ou num simples bate papo entre membros do time, você faz uso de uma palavra muito simples. Componente.

Você poderia estar compartilhando algo que você aprendeu em sua mais recente leitura, sugerindo outra maneira de desenvolver a interface gráfica ou estar fazendo apenas uma piada mesmo. Independentemente do que você estava fazendo, no exato momento em que você terminar de pronunciar a última sílaba desta palavra tão simples chamada componente, algo muito complexo vai começar a acontecer.

O designer vai invocar os poderes do deus Design System, ungido pela glória do Design Atômico e batizado com cada uma das variáveis de seu conjunto de Design Tokens. O Product Owner, enfeitiçado pela magia da reusabilidade—e asfixiado pelo gráfico de Gantt que lhe cobra a entrega de dezenas de novas funcionalidades—o indagará repetidas vezes: Então seria possível entregar mais telas em menos tempo?. E, por fim, o programador back-end se limitará a dizer: Já usei Bootstrap uma vez. Odeio CSS.

Embora tenha apenas quatro sílabas, a palavra componente provoca zilhões de diferentes interpretações e expectativas. Uma palavra tão fácil de pronunciar e tão difícil de definir.

Nesse momento, você deve estar convencido de que no próximo parágrafo vou apresentar uma definição para componente que vai causar um terremoto na sua mente. A definição que, uma vez pronunciada, é capaz de incinerar toda e qualquer ambiguidade.

Não cara, me desculpa. Eu infelizmente não encontrei essa única e toda poderosa definição. Mas vou tentar te ajudar oferecendo três! Elas compõem o que eu chamei de Modelo de Maturidade de Componentes.

Nível Zero: Caos

Bem vindos ao caos. Nesse nível, qualquer uma daquelas zilhões de interpretações ainda inexistem. Tudo se reduz a raça e coragem. Nada pode ser reutilizado e as mudanças são muito caras.

Anatomia

Efeitos Colaterais

Exemplo

<div class="finance-btn-attach-file glyphicons paperclip">
  <i></i>Attach documents
</div>

Um botão genérico de upload de arquivo foi acoplado a uma folha de estilo já relacionada a um domínio de negócio (finance). Comportamento e marcação não estão encapsulados e serão replicados usando outras classes e outra marcação onde quer que o botão seja utilizado novamente.

Nível Um: Componentes CSS

Estágio onde as estruturas HTML são padronizadas e as classes CSS podem ser reutilizadas.

Anatomia

Efeitos Colaterais

Exemplo

<button class="btn btn-primary">
  <i class="glyphicons glyphicons-download-alt"></i>Download
</button>

Estrutura HTML padronizada para um botão estilizado como primary e contendo um ícone à esquerda de seu texto. Todas as partes do sistema que precisam de um botão como esse, ao replicar essa estrutura com essas mesmas classes, são agora capazes de alcançar o mesmo resultado.

Nível Dois: Custom Elements

Seja muito bem vinda, produtividade! Esse é o estágio onde tudo, absolutamente tudo, está encapsulado em seu próprio componente.

Anatomia

Efeitos Colaterais

Exemplo

<my-button data-theme="primary" data-icon-name="paperclip">
  Attach Documents
</my-button>

O custom element acima, my-button, é a única parte do sistema onde qualquer coisa relacionada a todos os botões da aplicação é tratada.

Pois bem, a definição de componentes única e retumbante eu vou ficar te devendo, mas espero que essas três possam servir de base para explicar aos seus colegas de qual nível de componentes vocês estão falando, qual nível de maturidade vocês esperavam ter e qual nível gostariam de alcançar.

Fique por dentro das futuras atualizações:

Você pode ser notificado por RSS também.