É sério que você ainda não documenta o seu front-end?

Quando trabalhamos com vários times devemos sempre pensar em como manter tudo o que desenvolvemos padronizado, tendo a certeza de que estamos seguindo um styleguide.

Atualmente na Syngenta Digital desenvolvemos soluções em forma de aplicações mobile e aplicações web. Nosso foco é manter a qualidade no maior patamar possível. Dada a robustez de nossas aplicações, e, pelo fato de possuírem diversas camadas, sem que houvesse uma documentação das soluções em que estamos trabalhando e um padrão a se seguir, seria muito difícil manter a qualidade que desejamos.

Imagina por exemplo ter que implementar uma tela nova com vários componentes dinâmicos, que serão reutilizados em várias partes da aplicação, ou, que será reutilizada até mesmo por outros times. Desenvolver uma nova tela com componentes assim pode facilmente se tornar um problema. Como no exemplo abaixo:

· Um componente que deve possuir um empty state (estado inicial ou sem nenhum dado);

· Que deve se comportar de uma forma diferente ao receber dados;

· Ser responsivo

· Deve dar uma resposta a interação de um usuário

· Deve aceitar mudanças de padrão, como, por exemplo acompanhar as cores do tema da aplicação escolhido pelo usuário.

O problema fica ainda mais grave quando pequenas mudanças exigem que vários componentes sejam retestados. Esses testes seriam manuais e excessivamente repetitivos, algo que nem de longe é um cenário pratico ou ideal.

Quando falamos de documentação estamos pensando em uma forma de otimizar nosso trabalho de algumas maneiras como:

· Evitar retrabalho;

· Minimizar os riscos de desencontro de informações;

· Ter uma padronização;

· Ter uma única fonte de verdade.

Essas documentações técnicas nos ajudam no nosso fluxo de desenvolvimento de software aqui na Syngenta Digital, sem elas levaríamos muito mais tempo para fazer algo que não possui uma documentação, ou que não possui um padrão. Além do fato de essas funcionalidades desenvolvidas não teriam nenhuma confiabilidade.

Isso porque teríamos que perguntar para o time de Design se aquela implementação está ok, que por sua vez teria que se comunicar com o time de produto para ter certeza de que o usuário conseguiria utilizar aquilo que foi implementado.

Algo assim se tornaria facilmente uma dor de cabeça para nós aqui na Syngenta Digital, pois temos centenas de pessoas desenvolvedoras, que trabalham em mais de 40 times multidisciplinares ao redor do mundo todo, e, cada um desses times cuidam de um pedacinho das nossas aplicações. E é claro que queremos manter a qualidade do que fazemos, isso significa saber que todos esses mais de 40 times estão alinhados. E sabendo exatamente o que desenvolver e como desenvolver.

Além disso, você provavelmente já passou pelo problema de que a aplicação em que você está trabalhando, demore facilmente mais do que 5 minutos para buildar, e, geralmente queremos ver como o componente está, não sendo necessário ver como ele fica dentro do contexto da aplicação. Assim é um tempo a mais que temos que esperar para poder trabalhar na solução.

Por isso precisávamos de uma ferramenta que atendesse esses requisitos. Que nos auxiliasse no fluxo de desenvolvimento front-end, para que nossos times tivessem um melhor alinhamento e continuassem entregando um produto com excelência.

O Storybook nos ajudou a enfrentar esses desafios uma vez que tínhamos que lidar com várias implementações, e, onde essas necessitavam de um esforço ágil e bem definido.

O Storybook funciona como um ambiente de sand-box que nos auxilia no desenvolvimento ágil de todo tipo de componentes, já que possuímos soluções que compartilham o mesmo design. E que, muitas vezes podem demorar para buildar, assim não precisamos esperar 2, 5 ou 10 minutos para testar nosso componente, podemos fazer isso em segundos porque o Storybook tem um pequeno tempo de carregamento.

Nela encontramos a solução que desejávamos: Documentar o front-end das nossas aplicações e assim podendo testar os componentes desenvolvidos, de uma forma muito mais abstrata, isto é, sem nos preocupar com algumas variáveis.

As variáveis são:

· Contexto: um componente que só pode aparecer para um usuário;

· Regras de negócio: Comportamentos que o componente pode ou não possuir;

· Fluxos extensos: Ter que percorrer um fluxo do usuário apenas para poder chegar em um componente que deve ser testado;

· Retornos de API: Não precisamos esperar que que o back-end responda.

Isso não quer dizer que não vamos validar esses cenários em um dado momento no fluxo, mas a ajuda que temos, é que durante o desenvolvimento não queremos ficar nos preocupando com eles.

Já temos testes funcionais que precisam que tudo esteja implementado para funcionarem, mas também temos testes intermediários de front-end, que são realizados durante o desenvolvimento, e é aqui nessa etapa que o Storybook nos ajuda: desenvolver pequenos componentes, para que eles sejam mais fáceis de testar, documentar e reutilizar.

Mas como fazer isso?

E como falamos cada componente desenvolvido pode possuir vários estados diferentes, por isso trabalhamos no Storybook com o conceito de stories.

O Storybook tem uma UI bem amigável como podemos ver o exemplo da própria documentação, cada item abaixo é um elemento e cada item dentro do elemento é um storie:

Vamos usar o exemplo de um componente de header, que possui um empty state e depois muda conforme o usuário muda de tela.

Após fazer a configuração inicial seguindo a documentação do Storybook, basta importar os componentes criados para o Storybook.

import React from ‘react’;
import { Story } from ‘@storybook/react’;
import Steps, { StepsProps } from ‘./steps.component’;
import ProviderStories from ‘../provider-stories/provider-stories’

Cada Story é um snapshot do estado daquele componente naquele momento.

Abaixo vemos o empty state do componente steps:

Ótimo, mas o objetivo aqui é ver como o componente se comporta em usos diversos, por isso podemos criar quantas storys forem necessárias. Aqui podemos, por exemplo, ver o componente com 4 steps:

Isso tudo implementado de uma forma muito simples direto na UI do Storybook, basta usarmos o controlador “steps”. Podemos, por exemplo, ver como o componente se comportaria com 100 ou com 0 steps.

Mas e se eu precisar validar o estado do componente conforme o usuário vai avançando entre os steps?

Usando o controlador aqui definido como “currentStep”, podemos realizar esse evento, assim validando o funcionamento ou não do componente.

Esses controladores são definidos dentro do arquivo de stories. Nesse arquivo passamos os controladores e que tipo de controle é esse, podendo ser um texto, um número, um objeto etc.

import React from ‘react’;
import { Story } from ‘@storybook/react’;
import Steps, { StepsProps } from ‘./steps.component’;
import ProviderStories from ‘../provider-stories/provider-stories’

export default {
title: ‘Components/Steps’,
component: Steps,
argTypes: {
    label: {
        control: ‘text’,
        defaultValue: ‘title label’,
    },
    currentStep: {
        control: ‘number’,
        defaultValue: 0
    },
    steps: {
        control: ‘object’,
        defaultValue: [
            {
                title: First Step,
                content: <div>content</div>
            },
            {
                title: Second Step,
                content: <div>content</div>
            }
        ]
    }
  }
}

Entendemos então que o Storybook nos auxiliou no desafio de deixar nosso front-end documentado, mais bem estruturado e com mais chances de reutilizarmos os componentes já desenvolvidos.

Então pelo sucesso que foi implementar esse componente de header e muitos outros que temos rodando em produção aqui na Syngenta Digital. Enxergamos os benefícios porque, além de tornar os testes desse simples, confiáveis e ágeis, vimos também que uma vez implementado, reutilizá-lo ficou muito mais fácil, já que o Storybook funciona como um ambiente sand-box, nos economizando tempo e recursos durante o desenvolvimento. Concluímos então que essa ferramenta de documentação teve grande impacto na qualidade do produto desenvolvido e entregue ao usuário final.

Podemos dizer que agora temos um front-end muito mais bem documentado, mais confiável e com um elevado grau de reutilização.

Se você leitora(o) passou por algo parecido em sua jornada como desenvolvedor, acredito que vale muito a pena tentar o Storybook, ou outra ferramenta similar.