Penso, logo codifico — o que fazer antes de desenvolver o seu componente no Design System

Ao receber um protótipo de um componente, a vontade é de começar a escrever linhas de código como se não houvesse amanhã. No entanto, o amanhã sempre chega e isso pode sair com um custo alto, tanto para quem utiliza quanto para a equipe que desenvolve.

O processo de criação de um componente, a partir do momento em que recebemos as instruções de comportamento e o desenho do componente pelos designers, não se inicia diretamente no desenvolvimento do código fonte. Antes disso, se faz necessário algumas etapas para poder fornecer uma melhor experiência para o desenvolvedor que irá utilizar esse componente.

Customização e Produtividade

Antes de começar a desenvolvê-los, é importante estar claro e bastante alinhado com o time do design system, o quão customizável será esse design system, pois isso pode, em termos de desenvolvimento de software, acarretar em uma menor produtividade. Por exemplo, vamos supor que iremos fazer um componente do tipo button . Se o objetivo do projeto é ser o mais customizável possível, poderemos disponibilizar um componente que pode ser utilizado da seguinte maneira:

<my-button>
    <span class="button-icon icon-save"></span>
    <span class="button-label">Salvar</span>
</my-button>

Dessa forma poderemos “abrir” mais o componente para que ele seja mais customizável. No entanto, essa abordagem traz consigo mais “código” que o desenvolvedor precisa escrever. Uma outra forma é disponibilizar a label em forma de propriedades:

<my-button label="Salvar"></my-button>

Esta segunda abordagem traz mais controle visual das aplicações para o design system e acaba sendo menos customizável.

Não existe um certo e um errado, vai depender do objetivo da sua biblioteca de componente. Por isso, é importante ter essa decisão bastante clara antes de desenvolver.

A seguir mostrarei algumas dicas e o processo que eu utilizo antes de começar a desenvolver o componente.

1 - Benchmarking nos design systems de mercado

Nós precisamos ter uma lista de referências de design systems onde poderemos ver como eles criam o componente que você precisa desenvolver. Ao encontrá-lo, você precisa analisar:

Quais são as “partes” que compõe esses componentes?

Por exemplo, no caso de um select, ele é composto por outro componente do tipo options?

Quais são as propriedades e funcionalidades que eles disponibilizam para os desenvolvedores?

As outras bibliotecas disponibilizam métodos para dar foco no elemento de forma automática? Se fosse uma modal , existe um método para abrir/fechar o componente?

2 - Acessibilidade

Também precisamos fazer uma pesquisa prévia sobre como trataremos a acessibilidade, eu normalmente avalio os seguintes pontos:

• Como será a navegação via teclado?
• Como o usuário irá interagir com o leitor de tela?
• Quais tratativas serão responsabilidade do componente e quais serão responsabilidade de quem irá utilizar esse componente (desenvolvedores)?

Devemos levar em consideração que os componentes nativos, como button, select e checkbox, já são acessíveis para leitores de tela nativamente. Então, no caso de criação de um elemento customizável, você pode utilizar como base esses componentes para a criação de algo mais acessível.

Para o caso de componentes onde não temos um exemplo nativo, o Guia de boas práticas de acessibilidade da WAI ARIA contém várias técnicas que podem ser utilizadas para os leitores de tela, incluindo a navegação via teclado. Este guia está categorizado em componentes, então para o desenvolvimento de alguns componentes ele pode ser bastante útil.

3 - Entradas e saídas do componente

Definir previamente as entradas e saídas do componente pensando no valor para o usuário pode evitar muitas refatorações e quebras de comportamento.

Lembre-se de definir:

• Quais serão as propriedades de entrada do componente?
• Quais serão as saídas das propriedades dos componentes?
• Quais serão os tipos de entrada das propriedades?

O seu componente também pode precisar disponibilizar métodos que poderá facilitar muito a vida dos desenvolvedores, como, por exemplo: um método que, ao chamado, aciona o foco no componente. Com essas definições de negócio feitas, fica muito mais fácil fazer o TDD, pois podemos criar os testes baseados nessas regras.

4 - Independência do componente

Nessa etapa, precisamos pensar um pouco em arquitetura de software. O nosso componente precisa ser independente por si mesmo, depender de partes externas para funcionar, pode ser uma má prática de desenvolvimento.

O componente pode reutilizar outros componentes para compor ele, mas deve sempre evitar que ele necessite de outro componente externo a ele. Também podemos aplicar aqui o Princípio de Responsabilidade Única, e se perguntar: qual é a responsabilidade desse componente, se ele tiver mais de uma responsabilidade, será que ele não deveria ser outro componente?

Quais são as vantagens de ter essas etapas?

Evita breaking changes e permite melhor experiência para os desenvolvedores.

O bom planejamento de como este componente será utilizado pode evitar que ele seja utilizado para uma finalidade na qual não foi projetado, pode conter técnicas para prevenção de erro para os desenvolvedores.

Ajuda a prevenir refatoração dentro da própria tarefa ou no futuro. Não espere que você faça perfeito da primeira vez, a refatoração faz parte. No entanto, isso pode te auxiliar a não apagar o seu código inteiro e reescrevê-lo do zero.

E quanto tempo leva para fazer tudo isso antes de sair fazendo o componente?

Ao ver essas etapas você pode estar se pensando:

“Nossa, depois de receber o protótipo/handoff do componente, vai levar pelos menos um mês esses estudos até começar a desenvolver o componente!”

A minha dica sobre isso é:

• Seja simples nas suas pesquisas! Faça um rascunho em uma folha de papel mesmo.
• Estipule um prazo para definir esses requisitos. Eu sempre estipulo um prazo de 1 dia para fazer essas etapas. Porque se não definirmos um prazo, a pesquisa pode se estender durante dias e dias.
• Tire as dúvidas com outros desenvolvedores e peça a opinião deles.
• Assuma riscos! Em caso de dúvida extrema, em que você já tirou as dúvidas com outros desenvolvedores, e já fez uma pesquisa, assuma umas das escolhas. Pois depois que você colocar em produção você terá bastante feedback com relação a forma de utilização. É melhor ter alguma coisa, do que as dúvidas nos impedirem e acabar não tendo nada para entregar ao cliente.

É isso pessoal, espero poder ajudar alguém com essas dicas!