Construindo um Design System agnóstico a framework

João Victor Campos
OPANehtech
Published in
5 min readSep 12, 2022

Aqui no Banco Pan, o assunto Design System já faz parte da pauta desde 2019, quando foi lançada a primeira versão do Mahoe Design System.

A biblioteca do front-end tinha sido criada utilizando o framework Angular, que na época era o padrão utilizado na maioria dos projetos.

Ao passar do tempo a nossa stack foi ficando cada vez mais flexível, buscando atender da melhor forma cada tipo de produto.

Com alguns projetos usando diferentes tecnologias, sem compatibilidade com a biblioteca, tivemos um desafio interessante para solucionar: Como podemos centralizar os componentes do nosso Design System em um único lugar e disponibiliza-lo para uso de todos os produtos web de forma agnóstica?

A resposta para essa pergunta foi: Web Components!

Legal, mas o que é Web Components?

Para alguns (ou a maioria) pode não ser novidade, mas para que todos estejam na mesma página, abaixo temos uma definição rápida:

“Web Components é uma suíte de diferentes tecnologias que permite a criação de elementos customizados reutilizáveis — com a funcionalidade separada do resto do seu código — e que podem ser utilizados em suas aplicações web.”

Referência: MDN Web Docs — Web Components

Com isso, temos a liberdade de criar componentes que podem ser facilmente utilizados tanto em uma aplicação que usa Javascript puro como em outra que usa algum framework baseado em JS.

Implementação e tecnologias usadas

Criamos uma nova biblioteca do zero para que os produtos em produção que usavam a versão Angular do Design System continuassem recebendo suporte e que não corressem o risco de serem impactados.

1. Repositório

Optamos por utilizar um Monorepo com o Nx, assim todo o nosso ecossistema de bibliotecas e aplicações relacionadas ao Design System (Tokens, Components, Storybook e Landing Pages do Design System) ficam hospedados no mesmo lugar, facilitando a manutenção.

Como o repositório é inner-source, ele acaba passando pela mão de muitos desenvolvedores. Para garantir o padrão de qualidade em relação a testes unitários, lint e commits, utilizamos três ferramentas excelentes que são conhecidas no mercado: Husky, Prettier e Commitlint.

Referências:

Nx

Husky

Prettier

Commitlint

2. Design Tokens

A princípio, decidimos manter a mesma forma de construção dos tokens do Design System em Angular: Utilizando SASS. Com as variáveis sincronizadas com as nossas folhas de tokens da biblioteca no Figma, criamos arquivos separados de tokens que podem ser importados de forma global ou separada no projeto.

Hoje, existem diversas soluções que integram o Figma com o front-end afim de manter os tokens sincronizados, como o Style Dictionary, uma ferramenta open-source desenvolvida pela Amazon, somado ao uso do plugin Design Tokens no Figma.

Referências:

Style Dictionary

Figma Design Tokens

3. Componentes

Para a construção dos componentes, buscamos por uma ferramenta que pudesse nos ajudar na produtividade, já que criar Web Components nativo em alguns casos pode ser bem verboso.

Optamos por usar o Stencil: Um compilador de Web Components criado pela equipe do Ionic. É uma ferramenta voltada para construção de Design Systems, então temos diversos fatores que facilitam (e muito!) a nossa vida na hora de criar um componente agnóstico.

Além dos benefícios do Web Components nativo, alguns recursos extras são adicionados como o Virtual DOM, reactive data-binding, o uso de JSX/TSX e renderização assíncrona.

A forma de desenvolver um componente e a utilização da API é familiar para quem já possui experiência com frameworks ou bibliotecas modernas como o React. Isso ajuda bastante na curva de aprendizado.

Exemplo de um componente escrito utilizando TSX e recursos do Stencil

A mágica acontece após a compilação da biblioteca, o Stencil transforma os componentes em Web Components nativo.

Todos eles são testados com o Jest, garantindo que estão se comportando da maneira correta e evitando bugs.

DISCLAIMER: É importante ressaltar que não concordamos que o Stencil é uma bala de prata ou a solução definitiva para resolver todos os problemas na hora de criar um Design System. Há outras ferramentas como o Lit e Angular Elements, ou até mesmo o framework que é mais utilizado na empresa. Tudo depende do contexto que o Design System vai estar inserido.

Referências:

Stencil Docs

Ionic

Jest

Lit

Angular Elements

4. Documentação

Por último e não menos importante, temos o Storybook, uma ferramenta usada para documentar todos os componentes e tokens de forma simples.

No Stencil, é possível configurar para que seja gerado um arquivo markdown para cada componente que lista todas as propriedades que podem ser usadas nos componentes, os eventos, os estados e as dependências do mesmo em um formato que o Storybook consegue interpretar e exibir em uma página de documentação.

Caso tenha alguma alteração no componente, sempre que o Design System for compilado, os arquivos são gerados novamente, mantendo a documentação sempre atualizada sem muito esforço.

Claro que a documentação na maioria dos casos não se estende somente a essas informações, mas já é uma grande mão na roda.

Automatizando boa parte da documentação com apenas 3 linhas
Informações geradas automaticamente pelo Stencil

Referências:

Storybook

Stencil Docs - Readme Markdown File Auto-Generation

Storybook Docs — Working with MDX

O que colhemos de resultado?

Após a fundação da biblioteca e a criação de alguns componentes, lançamos as primeiras versões do Design System.

Para entender as necessidades e como deveríamos priorizar o desenvolvimento de novos componentes, estabelecemos Weeklys dentro das squads dos produtos. Com isso, tivemos um ótimo direcionamento para organizar o nosso backlog.

Abaixo, segue alguns dos nossos resultados:

  • Conseguimos atingir o nosso objetivo de ter uma biblioteca de componentes agnóstica e tivemos a oportunidade de usar em aplicações Angular, React/Next.js e JS Vanilla sem grandes problemas.
  • Mesmo com a atual versão tendo mais componentes que a antiga, conseguimos obter uma redução de 86% no tamanho do bundle final da biblioteca de componentes em relação a versão anterior.
  • Disponibilizamos o Design System em uma CDN para parceiros de desenvolvimento que não tem acesso ao repositório corporativo do Pan.
  • Os times de produto começaram a colaborar com a biblioteca inserindo novos componentes, corrigindo bugs e sugerindo melhorias. A curva de aprendizado de todos os devs foi muito rápida.

Quer conhecer mais sobre o nosso Design System? acesse a nossa página principal: https://designsystem.bancopan.com.br

Equipe

João Victor Campos, Pedro Delfino, André Garbeline, João Paulo Moura

--

--