Angular: construa um Design System com Nx e Storybook

Boas-vindas a mais um curso de Angular! Meu nome é Antônio Evaldo, serei o instrutor.

Audiodescrição: Antônio Evaldo se identifica como um homem branco. Usa óculos com armação arredondada, possui bigode e cavanhaque, e cabelos cacheados que estão soltos e na altura dos meus ombros. Veste uma camisa preta. Ao fundo, há uma parede iluminada por cores azuis que gradativamente se transformam em rosa.

Neste curso, vamos construir um projeto interessante utilizando Nx e Storybook.

Teremos o Figma de um design system de uma empresa fictícia chamada Alfabit, que exploraremos ao longo deste curso.

Esse design system já foi implementado pelo time de design dessa empresa. Portanto, possui muitos componentes, como botões com diversas variantes, checkboxes, campos, modals, entre outros.

Neste curso, vamos aprender a implementar o design system, focando nas variantes do botão.

Para isso, utilizaremos uma ferramenta chamada Storybook, que permite implementar uma documentação interativa com todas as variantes que estão documentadas no Figma.

Há uma seção para mostrar o código do botão, outra para controles, para alterar como ele está sendo exibido, e também as variantes dele, que chamamos de Stories.

Depois, aprenderemos como publicar esse componente, essa biblioteca, no npm, dentro de uma organização chamada alfabit-alura, que já está publicada em uma versão específica.

Após publicar esse componente, vamos verificar como consumir em uma aplicação externa.

O que vamos aprender?

Ao longo deste projeto, vamos aprender o que é um design system e por que uma empresa precisa de um. Em seguida, veremos como implementar esse design system por meio de um monorepo. Vamos entender o que é isso e como criar um monorepo com a ferramenta chamada Nx.

Depois, começaremos a implementar esse design system, utilizando também o Storybook, para criar aquela documentação interativa.

Trabalharemos nas variantes do botão, nas stories dele. Por fim, aprenderemos a publicar uma biblioteca e a consumi-la também no npm, com a ajuda de um recurso chamado Nx Release.

Ao final deste curso, você terá aprendido a criar um monorepo com o Nx, para implementar um design system com o Storybook.

Pré-requisitos

• Conhecimentos em Angular básico;
• Familiaridade com a linha de comando.

Bora para a primeira aula!

Imagine que fazemos parte da empresa fictícia Alfabit que tem um projeto no Figma e enviou esse Figma para nós.

A Alfabit atua na área de consultoria de software, fornecendo soluções sob medida para outras empresas. No Figma, podemos observar a landing page (página inicial do site), com o título "Alfabit, soluções sob medida para o mundo tech!", elementos como um botão de login no topo e uma seção central que destaca as soluções personalizadas oferecidas. O design da página é bonito e segue um padrão clássico.

Padronização visual no design da Alfabit

Durante a análise da landing page, identificamos várias padronizações no design. A paleta de cores, predominantemente branca e azul, mantém-se consistente, assim como o espaçamento, o tamanho das fontes e os estilos dos botões. Esses elementos já estão estruturados de forma a permitir a reutilização em outros projetos, como a criação de um site para venda de cursos.

Se fossemos codificar essa página, já pensaríamos em como reutilizar esses estilos. Poderíamos fazer isso utilizando componentes, como os componentes do Angular, por exemplo.

Mas, imagine que a Alfabit queira trabalhar em outros projetos também. Digamos que ela queira criar outro site para vender cursos, por exemplo. O importante é que nesses outros sites, a Alfabit quer manter esse mesmo padrão visual, essa mesma identidade visual e esse mesmo padrão de cores, espaçamentos e todos esses detalhes de estilos.

Como serão projetos diferentes, simples componentes não serão suficientes para reaproveitar todos esses estilos.

Além disso, se a equipe de design da Alfabit não tiver todos esses estilos padronizados ao criar esses novos projetos, certamente haverá inconsistências ao longo desses projetos. Um botão que deveria seguir um padrão de estilos, por exemplo, poderia ter um espaçamento diferente em outro projeto, ou uma cor ligeiramente diferente. Portanto, seria muito útil se pudéssemos padronizar todos esses estilos .

É por isso que a Alfabit decidiu adotar uma solução que chamamos de design system (sistema de design). Essa solução consiste justamente nessa padronização que estamos discutindo.

No projeto do Figma, podemos acessar o que a equipe de design fez até agora. Temos uma seção chamada "moléculas", que é uma das páginas desse Figma. Nessa seção, temos vários componentes. Temos muitas variantes do componente de botão, checkboxes, radio buttons, switch, inputs, modals, notices, blocos de texto e muitos outros componentes padronizados.

Também temos um calendário e os links que a Alfabit está utilizando naquele projeto. Isso que estamos acessando na seção "Moléculas" do Figma é um design system. É um sistema de design muito bem organizado e padronizado.

Vamos falar um pouco mais sobre essa terminologia de páginas que são divididas em:

• átomos;
• moléculas;
• organismos.

Átomos e moléculas

Começando pelos átomos, nesta seção temos os elementos mais básicos do nosso design system que compõem todos os outros. Temos todas as cores que são utilizadas no design system, todas as padronizações de tipografia para títulos H1, H2, H3, etc. Temos também padronizações de espaçamento, sombras, cantos arredondados, divisores, caixas e até um sistema de grid.

Chamamos isso de "átomos" porque, assim como na vida real, os átomos, quando juntamos, compõem moléculas.

É exatamente por isso que, na página de moléculas, temos todos os elementos que são formados por aqueles elementos iniciais, cores, fontes e espaçamentos. A partir deles, conseguimos formar as moléculas, que são os botões, os inputs, etc.

Organismos

Depois de moléculas, temos os organismos, que são formados pelas moléculas. Se clicarmos na seção "Organismos", temos dois exemplos, basicamente. Temos o header, que é composto por botões, com algumas variantes específicas, alguns textos e uma imagem do Alfabit. E também temos o footer, que é composto por algumas caixas e, principalmente, alguns textos, links e imagens.

Esse é o conceito que chamamos de Atomic Design. É um conceito que a equipe de design pode adotar ou não, é uma decisão de cada empresa. Quando adotado, fica bem organizado. Vamos segui-lo para implementar o design system.

Vantagens

• Reutilização de componentes;
• Facilita a manutenção e escalabilidade;
• Documentação e padronização;
• Reforça a identidade visual da empresa.

O Google, por exemplo, adota o design system porque reaproveita muitos componentes visuais em diversos sites diferentes, tanto no site principal, quanto no Meet, quanto no calendário. Existem muitos componentes que são reaproveitados ao longo de vários serviços do Google, por exemplo.

Essa é uma das vantagens de ter um design system. Como temos componentes reaproveitáveis, nem a equipe de design, nem a equipe de desenvolvimento, precisam criá-los do zero. É só reaproveitar o que já estava lá antes.

Outra coisa é que um design system facilita a manutenção e a escalabilidade dos projetos, porque como já está tudo padronizado e reaproveitável, basta mudar apenas o único local se quisermos realizar alguma alteração ou melhoria em algum componente.

Além disso, design system funciona como uma documentação, tanto para a equipe de design, quanto para a equipe de desenvolvimento. Se já utilizou o Figma para codificar projetos antes, sabe que quando temos uma padronização bem documentada, isso facilita muito a nossa vida na hora de desenvolver os projetos.

Por fim, como já mencionamos antes, um design system reforça a identidade visual de uma empresa ao longo de todos os seus produtos, se assim ela desejar.

Mas é importante dizer que nem toda empresa precisa de um design system. Essa solução é mais adequada para empresas que têm principalmente muitos projetos e querem manter essa padronização e identidade visual ao longo desses projetos. Se esse não for o caso da sua empresa, talvez não seja interessante aplicar essa solução.

Além disso, implementar um design system também requer investimento de tempo e de recursos, tanto da equipe de design, quanto da equipe de desenvolvimento. Portanto, a empresa precisa ter os recursos necessários para conseguir implementar essa solução.

Próximo passo

Qual é o nosso papel, como pessoas desenvolvedoras, nessa implementação do design system?

Como dissemos, ele já está feito no Figma, mas falta traduzir isso para o código. Vale lembrar também que, neste curso, não vamos fazer aquele projeto que mostramos no início do vídeo, que é o projeto da Alfabit. O foco será implementar o design system em si, que é isso que mostramos, de átomos, moléculas e organismos. Queremos traduzir isso para código.

Mas como vamos fazer isso e fazer com que esse design system seja consumido para vários projetos diferentes, para várias aplicações diferentes?

Vamos estudar isso a partir do próximo vídeo!

Já sabemos que a empresa fictícia Alfabit decidiu implementar um design system que já está pronto pela parte do time de design.

Agora, nós, como pessoas desenvolvedoras, estamos encarregados de traduzir isso para código, para conseguirmos reutilizar todos esses componentes ao longo de vários projetos e aplicações da Alfabit.

Em um primeiro momento, poderíamos pensar em implementar essa solução criando uma biblioteca e publicando-a no npm com os componentes Angular. Essa biblioteca poderia ser consumida por várias aplicações diferentes.

No entanto, essa solução tem um problema: se uma aplicação da Alfabit precisar de apenas um componente, ela terá que instalar a biblioteca inteira com todos os componentes. E, considerando que esse design system é grande, com o tempo, a biblioteca do design system ficaria bem grande também.

Assim, aplicações que precisam consumir apenas um ou poucos componentes do design system acabariam baixando uma biblioteca pesada desnecessariamente.

Existe uma segunda solução para resolver esse problema: implementar o design system ao longo de várias bibliotecas, onde cada biblioteca terá apenas um único componente ou poucos componentes, dependendo das decisões que decidirmos tomar.

A forma mais otimizada de deixar cada biblioteca o menor possível é colocando um componente por biblioteca.

No entanto, gerenciar várias bibliotecas é complexo e difícil. Temos que lidar com todas as versões dessas bibliotecas e também com as dependências entre elas. Por exemplo, seguindo o design atômico, teremos componentes que dependem de outros. O botão vai depender da tipografia, vai depender das cores do nosso projeto. Existem dependências entre componentes que serão refletidas nas dependências entre essas bibliotecas também, entre os pacotes que queremos publicar.

Foi com esse problema em mente que foi criada uma solução, uma ferramenta, que funciona como um gerenciador de bibliotecas e até mesmo de outros tipos de projetos. Essa solução é o nosso querido NX.

O NX é praticamente um gerenciador de aplicativos e bibliotecas e vai nos ajudar muito nessa situação de querer publicar e desenvolver várias bibliotecas.

Como o NX vai nos ajudar nesse caso?

Vamos abrir a página da documentação do NX que está na seção de tutoriais.

O tutorial em que estamos agora se chama Angular MonoRepo. O que é o MonoRepo? O MonoRepo é basicamente um repositório que guarda vários projetos em um único repositório.

Ou seja, podemos ter várias aplicações, várias bibliotecas, em um único repositório que podemos eventualmente publicar no GitHub, por exemplo. Então, tudo ficará em um repositório só.

Essa é a solução que o NX traz para facilitar esse gerenciamento de projetos, justamente porque quando fica tudo no mesmo repositório, também será mais fácil compartilhar alguns códigos, principalmente quando estivermos lidando com dependências.

Vamos seguir o tutorial para saber como criar um MonoRepo Angular.

Na seção "Creating a new Angular Monorepo", o tutorial fornece um comando para criar um MonoRepo Angular:

npx create-nx-workspace@latest angular-monorepo --preset=angular-monorepo

Vamos copiar esse comando, abrir o nosso terminal e colar o comando. Vamos alterar algumas coisas nesse comando.

O npx vai executar o pacote create-nx-workspace na versão latest, mas vamos alterar essa versão para 19.0.4.

Recomendamos que você utilize a mesma versão que está sendo usada no vídeo, porque dependendo da diferença de versão podem haver algumas mudanças do código ao longo do curso.

Em seguida, colocamos o nome do MonoRepo que queremos criar. O NX sugeriu o nome angular-monorepo, mas vamos alterar esse nome para alfabit-monorepo. A opção --preset=Angular MonoRepo trará o nosso MonoRepo já com várias configurações pré-prontas, para não precisarmos fazer isso manualmente.

Vamos executar esse comando no terminal:

npx create-nx-workspace@19.0.4 alfabit-monorepo --preset=angular-monoreеро

O terminal perguntou qual será o nome da aplicação. Vamos esclarecer uma terminologia que o NX utiliza, principalmente na documentação. Quando usamos o termo "projeto" podemos estar nos referindo a uma aplicação ou a uma biblioteca. Basicamente, são com esses dois tipos de projetos com os quais lidamos no NX.

Quando criamos um monorepo, precisamos criar ele com pelo menos uma aplicação dentro. É justamente isso que o NX está perguntando, vamos inserir "alfabit". Mas como já foi dito, neste curso vamos trabalhar apenas nas bibliotecas.

Depois de interagir com o terminal e responder algumas perguntas, ele começará a construir o nosso monorepo. Essa parte pode demorar um pouco.

The image shows a configuration setup, likely for a JavaScript/TypeScript project using a tool like Nx. Here's the transcription of the setup options:

Application name · alfabit

Which bundler would you like to use? · esbuild

Default stylesheet format · css

Do you want to enable Server-Side Rendering (SSR) and Static Site Generation (SSG/Prerendering)? · No

Test runner to use for end to end (E2E) tests · none

Do you want Nx Cloud to make your CI fast? · skip

Quando as dependências do projeto forem instaladas, vamos abrir o projeto no VS Code com o comando

code .\alfabit-monorepo\

O projeto vem com uma estrutura de pastas que vamos explorar um pouco mais adiante.

Por enquanto, vamos usar um comando que sabemos que o NX traz para executar a aplicação que veio no nosso projeto. Conseguimos até conferir essa aplicação na pasta "Apps". Temos a pasta apps\alfabit. Essa é a aplicação que está dentro desse MonoRepo. Vamos abrir o terminal integrado e executar o seguinte comando:

npx nx run alfabit:serve

Monorepo

Agora, falando um pouco mais sobre esse monorepo, quero mostrar a diferença entre o multirepo e o monorepo.

Na abordagem de multirepo, temos vários projetos, cada um com seu próprio repositório Git. Esses projetos podem ser aplicações ou bibliotecas, aplicações front-end, aplicações back-end, bibliotecas front-end, bibliotecas back-end. Existem muitas empresas que têm esses vários projetos, onde cada um tem seu próprio repositório. No entanto, quando queremos compartilhar código entre diferentes projetos, começa a ficar difícil. Sempre temos que fazer uma nova biblioteca para conseguir compartilhar código.

Esses problemas de compartilhamento de código e similares são resolvidos no monorepo. Temos vários projetos que continuam sendo separados. Continuamos tendo nosso projeto front-end separado do nosso projeto back-end, separado da nossa biblioteca, da nossa outra biblioteca.

A única diferença é que todos eles ficarão dentro de um único repositório Git, dentro de uma única pasta.

É como se tivéssemos uma única caixa de ferramentas, onde todas as ferramentas estão no mesmo lugar para fácil acesso, mas ainda temos que ter a responsabilidade de dividir as coisas corretamente, de gerenciar as coisas corretamente e deixar tudo em seu devido lugar.

É exatamente isso que vamos ver ao longo deste curso, utilizando o NX para gerenciar esse monorepo.