Sobre Design System, bit.dev e sincronização de componentes

[felipefialho]

Oi amgs, como estão?

Nos últimos dias tenho lido bastante sobre Design System e tentado me aprofundar no tema.

Todas as vezes que iniciei um DS, os processos eram meio manuais, ou seja...

• Repositório com a lib de componentes
• Publicação das alterações em pacotes no NPM
• Update da dependências nos projetos que utilizam

Isso funciona bem numa escala pequena, mas é um pouco complicado em projetos com muitas pessoas atuando ou quando é usado em vários lugares.

Com isso comecei a verificar algumas possibilidades para melhorar esse fluxo de sincronização quando Monorepo não é uma opção. E apesar de já conhecer antes, o bit.dev tem ganhado minha atenção.

Alguém já usou?
Podem comentar suas experiências?
Vale o preço?
Ja usaram outra alternativa nessa linha?

Obrigado!

[marcusvcribeiro]

Eu gosto bastante do storebook. Porém isso tudo aí é uma guia de estilo. Acho muito louco a galera tá confundindo o que realmente é um DS de um guia de estilo. Em Qui, 13 de fev de 2020 12:02, Felipe Fialho <[email protected]> escreveu:

…

Oi amgs, como estão? Nos últimos dias tenho lido bastante sobre Design System e tentado me aprofundar no tema. Todas as vezes que iniciei um DS, os processos eram meio manuais, ou seja... - Repositório com a lib de componentes - Publicação das alterações em pacotes no NPM - Update da dependências nos projetos que utilizam Isso funciona bem numa escala pequena, mas é um pouco complicado em projetos com muitas pessoas atuando ou quando é usado em vários lugares. Com isso comecei a verificar algumas possibilidades para melhorar esse fluxo de sincronização quando Monorepo não é uma opção. E apesar de já conhecer antes, o bit.dev tem ganhado minha atenção. Alguém já usou? Podem comentar suas experiências? Vale o preço? Ja usaram outra alternativa nessa linha? Obrigado! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/frontendbr/forum/issues/1691?email_source=notifications&email_token=AESKPRPJKL7K32WHLQD32ETRCVOJVA5CNFSM4KUUNKT2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INJJNIA>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AESKPRNGIARSLCQ464B6VT3RCVOJVANCNFSM4KUUNKTQ> .

[gabrielbs]

Passei por isso a tempinho atrás e no final das contas decidi que a melhor opção para mim era um Monorepo. Me interessei bastante pelo bit, mas depois que vi que a versão free era bem limitada (pelo menos na época) deixei pra lá.

Com esse tipo de arquitetura todo o processo de deploy e atualização de projetos fica muito fácil além de que é possível saber algo vai quebrar antes mesmo de publicar um package em qualquer lugar -- além de o processo de publicação nem ser obrigatório até você precisar de diferentes versões de um package em um projeto

Escrevi aqui como montei a minha arquitetura em Monorepo:

https://gabrielbs.netlify.com/pt-br/monorepo

[ninetails]

Ainda acho que monorepo ainda é uma saída mais viável quando é um projeto só. Para diferentes projetos com diferentes repositórios pegando componentes do mesmo repositório, neste cenário sim acho que vale a pena criar um repositório só pros componentes, porém começa a ter a necessidade de publicar isso pra algum registro (npm).

Também acompanho de longe o bitsrc e curto bastante a idéia que ele traz, mas não sei se vale a pena em relação a preço pois não cheguei a usá-lo a fundo. Se ter cada componente como um pacote, monorepo já satisfaz. Só pensar em deixar tudo da aplicação (seja componentes ou qualquer código) o menor possível e modularizado, e cada módulo virar pacote dentro do monorepo.

Também utilizo tanto Lerna quanto Yarn Workspaces igual o @gabrielbs falou.

[luanccp]

Ainda acho que monorepo ainda é uma saída mais viável quando é um projeto só. Para diferentes projetos com diferentes repositórios pegando componentes do mesmo repositório, neste cenário sim acho que vale a pena criar um repositório só pros componentes, porém começa a ter a necessidade de publicar isso pra algum registro (npm).

Também acompanho de longe o bitsrc e curto bastante a idéia que ele traz, mas não sei se vale a pena em relação a preço pois não cheguei a usá-lo a fundo. Se ter cada componente como um pacote, monorepo já satisfaz. Só pensar em deixar tudo da aplicação (seja componentes ou qualquer código) o menor possível e modularizado, e cada módulo virar pacote dentro do monorepo.

Também utilizo tanto Lerna quanto Yarn Workspaces igual o @gabrielbs falou.

Legal a forma como todos vem entendendo a necessidade de fazer o design system.
Mas você sabe se tem custo para publicar ou gerenciar esse registro (yarn ou npm)?
Tem como aplicar algum tipo de segurança para a sua utilização?

[ninetails]

Mas você sabe se tem custo para publicar ou gerenciar esse registro (yarn ou npm)?
Tem como aplicar algum tipo de segurança para a sua utilização?

Então, o npm é pago, US$ 7 por usuário para pacotes privados e o do GitHub tá em beta.

Mas tem como levantar registros privados dentro da rede, creio que os mais famosos são:

• Verdaccio
• Nexus OSS

Acho que sendo privado, ninguém externo acessaria por meios convencionais.

Só claro, tomar cuidado para não subir nenhuma secret da mesma forma que existe esse cuidado ao subir pro GitHub, mesmo privado.

[eliseumds]

Eu penso que vale a pena para empresas gigantes com diversos projetos diferentes, fora isso é queima de tempo. No nosso pequeno time nós temos uma bibliotecas de milhares de components num monorepo que não é publicado no NPM, é coisa interna. Usamos um style guide homemade parecido com Storybook que lista os principais componentes com diversos use cases, e só. Design Systems e publicação de components são coisas muito caras e totalmente desnecessárias pra maioria dos projetos.

[joaopavila]

Estou começando a fazer um Design system e acredito que devo seguir mais ou menos essa lógica.

• Criar projeto com NPM simples.
• Adicionar SCSS
• Criar alguma task para build SCSS to CSS ( mais para facilitar mesmo )
• Seguir o ATOMIC DESIGN ( Acredito que seja o melhor para esse caso )
• Adicionar changelog ( já configurar um changelog para facilitar nos commits para outras pessoas do time)
• Adicionar storybook

E para ver rodando, criar algum projeto básico para ver como vai ficando. O que acham?

[luanccp]

Estou começando a fazer um Design system e acredito que devo seguir mais ou menos essa lógica.

• Criar projeto com NPM simples.
• Adicionar SCSS
• Criar alguma task para build SCSS to CSS ( mais para facilitar mesmo )
• Seguir o ATOMIC DESIGN ( Acredito que seja o melhor para esse caso )
• Adicionar changelog ( já configurar um changelog para facilitar nos commits para outras pessoas do time)
• Adicionar storybook

E para ver rodando, criar algum projeto básico para ver como vai ficando. O que acham?

Você pensa em criar os componentes tudo com scss ou css? Eu tentaria fazer os componentes com Vanilla JS ou React (estilizando com Styled-components), mas isso depende da stack do seu time.. eu acredito.

[joaopavila]

Estou começando a fazer um Design system e acredito que devo seguir mais ou menos essa lógica.

• Criar projeto com NPM simples.
• Adicionar SCSS
• Criar alguma task para build SCSS to CSS ( mais para facilitar mesmo )
• Seguir o ATOMIC DESIGN ( Acredito que seja o melhor para esse caso )
• Adicionar changelog ( já configurar um changelog para facilitar nos commits para outras pessoas do time)
• Adicionar storybook

E para ver rodando, criar algum projeto básico para ver como vai ficando. O que acham?

Você pensa em criar os componentes tudo com scss ou css? Eu tentaria fazer os componentes com Vanilla JS ou React (estilizando com Styled-components), mas isso depende da stack do seu time.. eu acredito.

No caso eu preciso que seja apenas CSS, vou usar o SCSS para facilitar o desenvolvimento e buildaria para CSS pra usar na minha aplicação.
Vai ser "estilo bootstrap" que só importo as classes para usar o estilo dos meus componentes.
Caso precise envolver algo com JS, penso em usar ou VanillaJS ou TypeScript ( mas ainda estou levantando essa possibilidade ).
Posso estar enganado, mas acho que fazer em React não entraria nesse cenário, porque eu vou fazer só o design system.
Futuramente existe a possibilidade de criar uma LIB, aí sim penso em usar alguma lib/framework.

[klarkc]

Experimentamos o bit.dev ano passado, é muito difícil incorporar ele em projetos de diferentes contextos, a fragmentação de código e especificidade de cada contexto é bem única no nosso caso, e isso tornou a solução inviável, por enquanto.

Uma "alternativa" que usamos, e que acho q surtiu mais efeito (embora tenha sido em um projeto só) foi monorepo contendo um pacote de shared components com documentação pelo vuepress. Encaixou bem melhor no fluxo de trabalho.

[felipefialho]

Obrigado @klarkc

Mas acha que o bit.dev poderia "quebrar um galho" num projeto em andamento enquanto uma estrutura de monorepo é desenvolvida?

[klarkc]

Obrigado @klarkc

Mas acha que o bit.dev poderia "quebrar um galho" num projeto em andamento enquanto uma estrutura de monorepo é desenvolvida?

Enfrentamos alguns problemas para importar libs internas/externas na ferramenta, e o debug na ferramenta ainda era bem complicado tomando muito tempo. Mas se isso n for um problema pra vcs é bem possível. Até abri essa sugestão a fim de melhorar isso.

[victorferreira]

A solução que adotamos aqui na empresa foi ter uma instancia própria do Verdaccio e criamos uma lib com o TSDX. Assim fica fácil manter uma lib compartilhada em vários projetos sem precisar abrir o projeto publicamente. Uma vantagem dessa abordagem, pelo menos pro nosso time, é não ter que gerenciar uma estrutura de monorepo e modificar o workflow que cada projeto já utilizava. Fora que com uma instancia do nosso próprio registry é possível ter várias libs diferentes pra propósitos diferentes com versionamento próprio, e compartilhar vários helpers entre as aplicações.

[deppbrazil]

Deixo aqui minha opinião sobre o que aprendi de Design System no geral e alguns pontos importantes no processo:

O conceito:

• É um Sistema de Design;
• Galera confunde muito Design System com uma biblioteca de componentes ou style-guide;
• Design System é além do código e além do Sketch ou Figma, é cultura de Design;
• O principal objetivo de um Design System independente do produto sempre será a consistência de Design dentro da organização (empresa).

O que deu certo, e o que não deu:

• Um conceito básico para qualquer Design System na questão do ponta pé inicial, normalmente começa fazendo um inventário de Design do que se tem hj de padrões em: sites da empresa, app, back-office, etc... com isso o time dedicado na construção do DS vai definindo os tokens de Design que são: fontes, ícones, lógica de Design, espaçamentos, ilustrações, etc.. onde o Designer faz um guia de estilo no Sketch, Figma Adobe XD e por ai vai...

• Em mais alto nível já pensar na forma como o Design System vai se comunicar com o usuário mas ai entra na questão de Design Language que é um pouco mais avançado pois envolveria UX Writer, UX Research, enfim... isso acaba acontecendo organicamente com a evolução da cultura de Design...

• E em paralelo o time de tecnologia começar a pensar no que usar de stack baseado nos princípios do DS e na estratégia da empresa...

• Um ponto importante é definir como vai fornecer esses estilos para as aplicações, ai vem a parte dolorosa e onde grande parte apanha muito aqui, já vi casos em empresas onde pessoas que nem vão meter a mão no código do Design System define de como o Design System tem que ser e em que linguagem tem que ser construído pq tal empresa fez assim, WHT pera ai?

é sério, isso acontece e é normal acontecer, lembre-se a cultura de Design está sendo constuída... rsrs

• Outro ponto, muitas pessoas confundem biblioteca de componentes com o Design System em si e não são a mesma coisa, já ouvi casos de falarem que o Bootstrap é um Design System, mas isso não é vdd, ok? Pra mim ele é um framework, e eu te comprovo isso pelo seguinte fato, pegue 3 sistemas usando ele e os compare, na grande maioria das vezes eles vão ser visualmente diferentes pois é aberto e vc pode fazer um o mesmo componente de várias formas sem um padrão visual pois ele não te educa a usar da forma correta pra determinado componente, apenas te orienta em como chamar aquele estilo...

• E porque bato muito nessa tecla, pois pra mim o Design System é um processo evolutivo de construir uma cultura de Design escalável e orgânica e não apenas um produto onde temos uma lib ou framework que vc da o npm install e chama a classe css button__primary e tá tudo certo...

• É importante frisar, a biblioteca de componente é uma pequena parte do Design System, onde no caso você pode ter uma lib em React onde vai fornecer esses estilos para uma aplicação React talvez uma lib em Angular onde vai fornecer para aplicações Angular que já estão rodando e não compensa refatorar pra React, uma em Vanilla com SASS para html estático e por ai vai...

• Mas também não saia fazendo bibliotecas para todas stacks existentes, pense que vai precisar dar manutenção nisso no futuro...

• Pode se pensar também em algo um pouco mais agnóstico servindo vários tipos de stack como: React, Angular, Vue, Estático, etc... bebendo do mesmo core, ai no caso o uso de algo pra compartilhar variáveis e estilo e dar output em outros formatos é algo a se pensar inicialmente também pois já vi em muito casos pessoal achando que aquela biblioteca em React vai resolver tudo e poder aplicar em tudo até naquele site institucional em PHPzão, calma não cometa esse erro❌, não venda essa ideia para seu chefe dessa forma...

Se quiser saber mais sobre Design System agnóstico olhe esse projeto do AirBnB o Lona

• Além de dar consistência na cultura de Design da empresa o Design System também tem que resolver uma dor inicial no seu nascimento para as pessoas verem valor, seja melhorando um produto já existente ou construir um novo já usando o DS, isso não é uma regra varia de empresa e times, ok? Mas não vai achando que vai conseguir aplicar em todos os projetos novos e legados da empresa com a primeira versão da sua biblioteca e com apenas uma biblioteca.

Sobre ferramentas:

• Para inspirações:
  • Adele: melhor site que achei para dar uma bizoiada nos DS do mercado;

---

• Para a construção dos tokens de Design:
  • Sketch: é top mas lembre-se que precisa de macOS para usá-lo;
  • Figma: top e colaborativo, da pra usar pela web, pessoal reclama que a prototipagem poderia ser melhor;
  • Adobe XD: se a empresa já usa o creative cloud é uma boa pois fica tudo integrado, eu particularmente acho meio bugadão, e tome cuidado que quando atualiza o SPEC muda o link de compartilhamento;
  • Invision: achei show de bola, na mesma pegada no Figma;

---

• Para documentar o Design System e UI:
  • Zeroheight : leve e intuitivo para documentar textos e tokens, integra com o Sketch e Storybook;
  • Storybook: a proposta de documentar o Front é muito boa, porém a configuração das stores são um pouco chatas;
  • DocZ: Intuitivo leve e fácil configuração;

---

• Para construção da biblioteca de componentes e afins:
  • React: pra mim a melhor opção no momento;
  • Angular: bom porém nem tudo usa-se ele em uma empresa que tem React como stack tb;
  • Vue: não cheguei a usar, mas falaram que é semelhando ao React porém com uma curva de aprendizagem menor;
  • Lerna: para gerenciar monorepos
  • Um dos maiores cases de monorepo: o famoso Babel

---

• Para web componentes e bibliotecas agnósticas:
  • Svelte
  • Stencil

Minhas considerações finais:

• Vale ressaltar que o Design System não é bala de prata;
• Ele não garante que um produto ruim vai se tornar um produto excelente apenas por aplica-lo;
• No início não saia codando loucamente a fim de mostrar agilidade e velocidade em ter uma biblioteca de componentes o mais rápido possível baseada nos tokens de Design, defina os objetivos antes, pois pode ser que precise refatorar a arquitetura inicial dele dependendo da estratégia da empresa e o que as pessoas esperam dele;

Ficou extenso mas tem bastante coisa legal que aprendi sobre o assunto que pode encurtar o caminho pra quem ainda não passou por isso! 😄

[deppbrazil]

Linkando essa issue #1506 acho que faz sentido os insights que temos aqui tb... 😄

[klarkc]

Um cara que estou querendo testar a um tempo é esse Tailwind CSS, por ser baixo nível (mas não tão baixo quanto o Vanilla CSS ou JS), ele se encaixa bem com a ideia de um design system adaptável a qualquer contexto.