Escalando a entrega de UI com o Storybook- parte 1
Cada vez mais temos aplicações web mais complexas com vários fluxos e com o layout mais apurado. As telas vêm sendo projetadas para servir ao usuário uma explosão de cores, interações, animações, texturas, sensações, ufa! Vocês devem imaginar o trabalho que dá para fazer e dar manutenção isso tudo, ainda mais com equipes que estão crescendo e ficando multiespecializada, possuindo várias roles como Frontend, Backend, Devops, Designers, entre outras roles.
Uma coisa é fato, manter todo esse código é complicado, mesmo quando temos testes unitários, mas, e o visual? Como fazemos o desenvolvimento da parte visual da aplicação escalar?
Não importa a arquitetura usada, temos que criar um Hall de Componentes Genéricos! Estes darão a cara da aplicação servindo de peças de Lego para construir cada tela e nos fará economizar de forma exponencial o tempo de desenvolvimento, e, assim reduzindo o tempo de entrega. Definição de felicidade!
O processo de Desenvolvimento
Se imagine um lugar onde nada existe, somente uma tela em branco e você tem que começar a desenvolver sua aplicação. Você, sabiamente, já verificou o layout das telas que tem que desenvolver e mapeou os componentes que irá precisar para criar sua primeira tela. Todo animado, criou os componente, colocou na linda telinha, está tranquilo, está tudo ali.
Agora, feche os olhos e se imagine no caos! Cheio de fluxos e condições para você visualizar aquele bendito componente que tem que atualizar o layout. Então, dolorosamente, você vai fazer todo esse fluxo para ver aquela mudança necessária, ou, irá fazer algumas gambiarras para poder visualizar mais fácil.
Gambiarras como comentar todo o código de uma página e colocar somente o componete, tirar uma validação para chegar no componente, criar uma pagina nova só para ter acesso ao componente… Já vi muitas dessas gambiarras por ai, e eu mesmo já fiz.
Concordamos que seria bem mais fácil, menos doloroso e mais produtivo se não precisássemos correr toda essa maratona. O ideal é que haver uma forma direta de acessar esse componente, e melhor, isolado da aplicação.
O Storybook pode nos ajudar
Em poucas palavras, o Storybook é uma biblioteca de visualização templates. Nela você pode plugar qualquer projeto de Frontend usando qualquer framework e visualizar os componentes e tudo que tem nele. Assim você pode montar o que quiser, porém, sem a necessidade de inicializar a aplicação.
Sua UI lembra muito aquelas páginas de demonstração dos Frameworks de CSS, com um menu lateral contendo as features e um container com a demonstração dessas features. E é exatamente para isso que ele serve, para demonstrar os componentes da aplicação servindo de documentação visual dos componentes, e, por que não, de outras coisas (fica da criatividade da equipe).
Plugando o Storybook
O Storybook possui um vasto suporte para os mais conhecidos Frameworks de Frontend, conforme tabela abaixo:
O processo instalação do storybook é bem simples, irei demonstrar com Angular, porque é o que eu mais uso.
O primeiro passo é instalar o storybook e informar o type de aplicação você está usando, qual framework.
npx -p @storybook/cli sb init --type angularO Storybook/cli vai fazer toda a configuração para você começar a usar com tranquilidade. No final das contas o que ele faz?
- Instala as dependências do Storybook;
- Cria os arquivos de configuração de inicialização, do registro dos addons e a configuração do typescript(tsconfig) e os typings ;
- Cria umas stories de demonstração na pasta src/stories;
- Adiciona os scripts de iniciar o server e build o storybook no package.json;
Então para rodar esse camarada é só utilizar script que o cli adicionou no package.json;
yarn storybookO server será iniciado e pronto para ser acessado no endereço localhost:6006 e você poderá ver as stories de demonstração do storybook.
Por default o storybook irá ler todos os arquivos terminados com *.stories.ts, mas pode ser configurado, pelo arquivo .storybook/config.js.
Criando nossas próprias stories
Supondo que vamos, por exemplo, definir nossa tipografia, então, podemos criar nossa primeira story. Como se trata do Design System vamos criar o arquivo na pasta src/stories/design-system.
mkdir ./src/stories/design-system
touch ./src/stories/design-system/typograpy.stories.tsE vamos adicionar o estilo mais simples possível aqui para nossa tipografia. Editando o src/assets/syles.scss da aplicação.
Vamos destrinchar essa story.
O método storiesOf vai receber o nome da feature que iremos demonstrar e para cada demonstração precisamos definir uma story com o método add, que também recebe um nome para essa story.
Além do nome, o método add recebe uma função que irá retornar nossa story. Esta story é um objeto que possui as propriedades template e styles.
O template que contém o html que será renderizado no pelo server do Storybook. Nele, você pode escrever estuturas para demonstrar os componentes ou mesmo as classes de css do Design System da aplicação, neste caso está usando as classes h1, h2 e h3 vindas do styles.scss da aplicação. Você pode também usar as classes de css definidas na propriedade styles, se for necessário criar alguma.
Habemus, primeira story
Resumindo, definimos um template html que está usando o css da aplicação e o da story. Para usar os componentes da aplicação é o mesmo princípio, porém temos duas maneiras de criar stories para os componentes: via declaração de template ou declaração de componente.
A declaração de template nós já vimos faz, para componentes é um pouco diferente, mas nada complicado. Basta importar o component e declarar na propriedade component. Como sempre, temos que passar algum Input para o component, por isso já estou incluindo inputs para essa story.
A story possui uma propriedade props que ela fará a comunicação da story com o component, passando todas as propriedades necessárias para o funcionamento do componente.
Nosso componente é bem simples, ele recebe dois Inputs e faz o bind no template.
Agora se for necessário usar o template para demonstrar um componente, ao invéz de utilizar a propriedade component, a coisa fica um pouco diferente. É necessário definir módulo e injetar no story, isso por que o Storybook cria um módulo dinâmico por contexto de stories. Então para utilizar um componente em um módulo é necessário declará-lo.
Quem é responsável por criar este módulo é o moduleMetadata que herda, não diretamente, da interface NgModule do Angular. Depois de criado basta injetar na story pelo método addDecorator. Esta injeção de dependência será usada em todas as stories deste contexto.
Conclusão
O Storybook é uma ferramenta que eu venho usando há quase 2 anos tanto para React, por onde eu conheci, quando para Angular, e vem me ajudado muito nas entregas da minha equipe.
Podemos, sem medo, parelelizar tarefas para entregar uma feature que, a princípio, demoraria pela interdependência de criação de componentes.
Além disso reduziu exponencialmente o retrabalho de criação de componentes, pois todos os componentes compartilhados estão documentados pelo Storybook.
Ficou muito mais fácil debuggar e atualizar o funcionamento de um componente sem a necessidade de fazer integrações com a aplicação para conferir o comportamento.
Para este post eu passei uma breve introdução das funcionalidades do Storybook, nos próximos eu irei demonstrar mais funcionalidades e casos de uso.
