DEV Community: Klaus Kazlauskas

The saltiest and wrongest article about Big O ever

Klaus Kazlauskas — Mon, 24 Nov 2025 16:55:00 +0000

Sigh... So you want to learn about Big O Notation huh? Welp, you came to the wrong place, but stay for the ride AS YOU WALK INTO MY RANT ABOUT THIS THING FOR 20 PARAGRAPHS! YES, I'M SCREAMING.

Nobody talks like that

Ok. Maybe some people do, but it is VERY specific and rare. What am I talking about? Look at this function:

function foo(list) {
  const foo = [];

  list.forEach(item => item.bars.forEach(bar => foo.push(bar)));

  return foo;
}

If you just thought "Oh, that is an O(n^2)" then you are a Big O pervert. Sorry. I don't make the rules.

In 15 years of web development, nobody ever reached out to me and talked in Big O terms. People would reach out to me and say "Yeah, that function is doing a nested loop. Maybe we can figure out a way of not doing it", like decent people.

But hey, Big O is not that bad, and there might be scenarios where you need to talk like that. Like, when doing interviews. So when an interviewer asks you "What is the complexity of the function?" you know how to answer, and then proceed to never use it ever again. Or when you need to prove to the C-suite that an optimization needs to happen, so you present some calculations, which they don't understand but nod either way, and they might approve it if there is some lingering "let's make devs happy" budget.

With all that said... That is not a problem with Big O itself. That is just how it is used in the industry. I think that understanding Big O is actually helpful. You can think more about how a function can become a bottleneck pretty easily by thinking how bad does it scale to infinity. Talking about that...

Infinites can be bigger than others, but why care?

THEY CAN, OK?! Some of them are almost the same, but others? They are entirely different beasts. Let's look at these two functions:

function badFoo(list) {
  const bar = [];
  const bibar = [];
  const tribar = [];

  list.forEach((item) => { bar.push(item) });
  list.forEach((item) => { bibar.push(item) });
  list.forEach((item) => { tribar.push(item) });

  return { bar, bibar, tribar };
}

function goodFoo(list) {
  const bar = [];
  const bibar = [];
  const tribar = [];

  list.forEach((item) => {
    bar.push(item);
    bibar.push(item);
    tribar.push(item);
  });

  return { bar, bibar, tribar };
}

Both functions are O(n). One of them is obviously way worse than the other. It should be an O(3n). It actually is that, but if you present that as is someone will pop up saying "Um... Actually. While that is technically correct, you need to drop that constant as it is not a factor that depends on the n. We are only interested in how the function scales to infinity."

You know what? This is what we are doing. It is a WAY bigger growth rate than just O(n). Which leads to a bigger infinite. I would understand if we were talking about sums, but multiplications?

Look at the chart below:

We can see that the Green line is worse than the Red, but it is basically following the same growth path. But take a look at the Black line there. That thing is getting farther and farther as the number of items grow. And how are all of them described? O(n).

I'm tired

Look, this all probably makes sense to a lot of people and it is correct and all. It comes from math and it has been used for many generations. The objective is to look for the part of the function that actually grows the fastest to infinity. Big O notation is just trying to simplify and highlight the issue.

That said, fuck you Big O, Theta, Omega, and the rest of your family as well. Nobody will come to your funeral.

Resources

Big O chart: https://www.desmos.com/calculator/kgwiv5zizm
Header image: dev.to AI image generator
Article images: Gemini Nano Banana

Make your life easier with Set Compositions

Klaus Kazlauskas — Tue, 20 Aug 2024 12:05:00 +0000

Finally! When Set was introduced in the past it already made our lives better. We were able to easily generate unique lists, but also have better performance on finding and setting items on those lists.

That was great, but we were still missing several things that other languages had. And this is true, because we were. With the new composition methods added to Set in 2024, we will finally be able to do union, intersection, difference, and more with simple calls.

Without any further ado, lets jump on it.

Difference

Returns a new Set containing elements that exist in the first Set but not in the second.

Example: You want to see which users visited the site in this week that didn't visit last month.

How to use it?

const thisWeekUsers = new Set([1, 2, 3, 4]);
const lastMonthUsers = new Set([3, 4, 5, 6]);

const newUsers = thisWeekUsers.difference(lastMonthUsers);

console.log(newUsers); // Set(2) { 1, 2 }

How we would do that in the past?

const thisWeekUsers = [1, 2, 3, 4];
const lastMonthUsers = [3, 4, 5, 6];

let newUsers = thisWeekUsers.filter(x => !lastMonthUsers.includes(x));

console.log(newUsers); // (2) [1,2]

Learn more at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/difference

Intersection

Returns a new Set with only the values that are present in both Set.

Example: You are adding an e-books bundle to the cart, but you already had some of those books there.

How to use it?

const booksBundle = new Set([1, 2, 3, 4]);
const cart = new Set([3, 4, 5, 6]);

const booksToAdd = booksBundle.intersection(cart);

console.log(booksToAdd); // Set(2) { 3, 4 }

How we would do that in the past?

const booksBundle = [1, 2, 3, 4];
const cart = [3, 4, 5, 6];

const booksToAdd = booksBundle.filter(book => cart.includes(book));

console.log(booksToAdd); // (2) [3, 4]

Learn more at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/intersection

Symmetric Difference

Returns a new Set with the values that do not repeat in neither groups.

Example: Checking overstocked items between stores to check which items can be exchanged.

How to use it?

const firstStore = new Set([1, 2, 3, 4]);
const secondStore = new Set([3, 4, 5, 6]);

const overstockedItems = firstStore.symmetricDifference(secondStore);

console.log(overstockedItems); // Set(4) { 1, 2, 5, 6 }

How we would do that in the past?

const firstStore = [1, 2, 3, 4];
const secondStore = [3, 4, 5, 6];

const allItems = [firstStore, secondStore].flat();
const overstockedItems = allItems.filter(item => {
  return !firstStore.includes(item) || !secondStore.includes(item);
});

console.log(overstockedItems); // (4) [1, 2, 5, 6]

Learn more at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/symmetricDifference

Union

Returns a new Set with the values from both groups but without repeating any values.

Example: You and your friend want to merge playlists, but some music are the same.

How to use it?

const yourPlaylist = new Set([1, 2, 3, 4]);
const friendPlaylist = new Set([3, 4, 5, 6]);

const mergedPlaylist = yourPlaylist.union(friendPlaylist);

console.log(mergedPlaylist); // Set(6) { 1, 2, 3, 4, 5, 6 }

How we would do that in the past?

const yourPlaylist = [1, 2, 3, 4];
const friendPlaylist = [3, 4, 5, 6];

const mergedPlaylist = new Set([yourPlaylist, friendPlaylist].flat());

console.log(mergedPlaylist); // (6) [1, 2, 3, 4, 5, 6]

Learn more at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/union

Is Disjoint From?

It returns a Boolean. It is true if both Set have no values in common, and false if they have at least one value in common.

Example: See there are products that are part of other groups.

How to use it?

const electronics = new Set([1, 2, 3, 4]);
const furniture = new Set([3, 4, 5, 6]);
const groceries = new Set(['apple']);

console.log(electronics.isDisjointFrom(furniture)); // false
console.log(electronics.isDisjointFrom(groceries)); // true

How we would do that in the past?

const electronics = [1, 2, 3, 4];
const furniture = [3, 4, 5, 6];
const groceries = ['apple'];

function isDisjoint(array1, array2) {
  return array1.every(item => !array2.includes(item));
}

console.log(isDisjoint(electronics, furniture)); // false
console.log(isDisjoint(electronics, groceries)); // true

Learn more at: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set/isDisjointFrom

Is Superset/Subset Of?

These two functions are very similar. They both return a Boolean value, and are direct opposites. Superset will return true if the Set is a superset of another, and Subset will return true if the Set is a subset of another.

I'm putting those functions together because knowing the answer to one of them is enough to know the other. A Set can only be a superset of a subset Set.

Example: Understand if users are part of a company group.

How to use it?

const itDepartment = new Set([1, 2, 3, 4]);
const genZFromToronto = new Set([3, 4]);

console.log(itDepartment.isSupersetOf(genZFromToronto)); // true
console.log(genZFromToronto.isSubsetOf(itDepartment)); // true

How we would do that in the past?

const itDepartment = [1, 2, 3, 4];
const genZFromToronto = [3, 4];

console.log(genZFromToronto.every(item => itDepartment.includes(item))); // true

Learn more at:

Now you are all Set ~~I'm not sorry~~ to use it in your project!

Let me know if you are also excited about it, another feature, or want to see something else covered. Until next time o/

TIL: Gemini can analyze errors directly on the browser

Klaus Kazlauskas — Sun, 18 Aug 2024 16:00:00 +0000

So, I was using Chrome's console to debug something today when I noticed a bulb icon on the right side of it saying "Understand this error". I clicked it, accepted the warning message saying the data will be sent to Google, and voila! The error was explained to me.

Here is on app they provide to test: https://bubble-jingle.web.app/search

The example app forces a CORS error, and when you click to understand it, it explains what is a CORS error, what is the problem, and some possible solutions.

This feature is called Console Insights, uses Gemini, and it should be on by default if you have Chrome v125 and meets their other requirements. If it is not turned on for you, check their requirements: https://developer.chrome.com/docs/devtools/console/understand-messages

Keep In Mind

On their own article they describe some issues to be aware, like prompt injection and wrong explanations.

Another point is how the data is used. Be sure to only submit data or have the feature on if you agree and trust how they are dealing with it: https://developer.chrome.com/docs/devtools/console/understand-messages#data-use

Conclusion

AI is for sure not perfect and there are many issues around it, but I would love to have something like that when I was beginning. That said, it will for sure make my day-to-day easier (when it doesn't hallucinate).

Hora de substituir o Redux

Klaus Kazlauskas — Sat, 27 Apr 2024 13:09:35 +0000

Olá pessoas! Vamos deixar claro desde o início que Redux não é ruim. Ruim é a forma como usam ele. Eu uso o ele desde 2016, e muitas vezes vejo as pessoas cometendo os mesmos erros. O principal? Querem usar Redux para tudo.

Muitas vezes as pessoas começam usando Redux para resolver problemas que fazem sentido, mas logo começam a cair na armadilha de adicionar o resto da aplicação para fazer sentido o investimento em usar o Redux. "Fica mais fácil e tudo centralizado" eles dizem, mas na maioria das vezes não fica.

Mas, o que é esse tudo o que eu to falando?

O que é tudo?

Estados locais como coisas visuais e formulários, estados de uma única página como query strings de URL, estados simples e não compartilhados, e requisições simples que não precisam ser cacheadas.

Você consegue resolver todos os problemas de cima com soluções simples, porque todos esses problemas são simples. Redux é complexo porque é feito para resolver problemas complexos. Mas como falei, muitas pessoas insistem em usar isso como uma bala de prata que funciona para tudo.

Não só você está tornando seu código mais complexo, como também está introduzindo mais responsabilidades pra você. Em vez de ter um estado que some quando o componente ou Context são destruídos, agora você tem um estado global cacheado que só será limpo se você tomar uma ação. Gerenciar cache é complicado, e o Redux puro não é a ferramenta aconselhada pra isso.

Os melhores casos pro Redux são estados complexos e com muitas interações. Isso não sou nem só eu que digo. Desde 2016 essa é uma opinião popular compartilhada por várias pessoas, incluindo um dos criadores do Redux e também está no próprio site do Redux.

Dito tudo isso... Até nesses casos eu ainda aconselharia outras opções além do Redux.

Mas qual é o problema do Redux?

Na real, são problemas. Não existe nenhuma opção na vida que seja perfeita. Tudo tem pontos positivos e negativos, e o Redux não é excessão. Além disso, na minha opinião, já surgiram muitas outras bibliotecas que resolvem os problemas que o Redux tenta resolver e de forma melhor.

Os principais problemas pra mim são a quantidade de código, e a gerenciamento de cache.

Quantidade de código

Recentemente eu troquei várias páginas de um projeto que estava usando Redux por @tanstack/react-query e a redução foi de mais ou menos 50% do código. Mesmo contando com yarn.lock, configuração pra testes e do projeto, ainda assim eram 200 linhas adicionadas pra 360 removidas.

Por que isso? Porque Redux não era a solução ideal pra isso, mais especificamente, Redux Toolkit. Bem provavel que o RTK Query (Redux Toolkit Query) também reduzisse bastante as linhas de código, mas no final as soluções apresentadas pelo @tanstack/react-query eram melhores pro nosso projeto.

Outro exemplo são estados compartilhados e globais. Se eles ainda são simples ou não mudam muito, como permissões, tema, ou lingua, você pode muito bem manter eles em um Context. O código pra manter isso é muito menor, e mais fácil de entender.

Gerenciamento de cache

Redux e RTK (Redux Toolkit) em si não foram feitos para gerenciar cache. RTK Query foi. Não só ele, como várias outras ferramentas. Mas o que eu quero dizer com isso? Que quando você tenta usar apenas Redux ou RTK, você terá que desenvolver todas essas técnicas. Você vai ter que pensar nos items a seguir e muito mais:

Quando que devemos eliminar/invalidar o cache?
Quando que o cache vai estar "vencido"?
Vamos usar parte dos dados primeiro e fazer um request por trás?

São várias pequenas decisões, onde cada uma traz seus problemas, e que a responsabilidade de planejar todas elas passou a ser nossa. Não precisa ser assim. Como falei antes, tem ferramentas que já fazem isso pra gente. RTK Query, TanStack Query, Apollo Client, etc. Todos eles tem várias ferramentas para poder lidar com o cache. Nós ainda temos a responsabilidade de saber como e onde usar, mas não precisamos desenvolver toda a lógica por trás disso e seus bugs.

Conclusão

Pare de usar Redux para tudo. Problema simples, solução simples. Como o pessoal fala use o KISS (Keep it simple stupid) ou a versão brasileira, o MSO:

Espero ter ajudado, e até a próxima \o/

Simplificando Feature Flags com DevCycle

Klaus Kazlauskas — Mon, 10 Jul 2023 15:26:45 +0000

Se você já tentou criar Feature Flags na mão, você sabe o inferno que é. Você tem que pensar em ...

Alterar feature flags sem precisar de deploys;
Ter configuração pra diferentes ambientes;
Dar acesso a quem precisa criar/configurar feature flags;
Saber se uma feature flag é usada e pode ser deletada;
Teste A/B, widget de feature flags, grupo de usuários, gereciamento por API, criar e dar manutenção pra solução ...

Então, pra que inventar a roda e não simplesmente usar uma coisa pronta? Ai que entra o DevCycle.

Mas... por que o DevCycle? 😐

Além de eles terem SDKs para a maioria das grandes linguagens e plataformas, e também terem uma API para gerenciar feature flags, eles tem integrações com outros serviços e uma CLI própria. Com esses dois últimos, tu vai poder saber onde suas feature flags estão implementadas e REMOVER AS FEATURE FLAGS COM UM COMANDO.

Essa plataforma tem váááárias outras coisas fodas, mas essas duas últimas foram as que mais me pegaram no coração. Lógico, existem outras paltaformas como LaunchDarkly e Harness que oferecem serviços parecidos ou até melhores que o DevCycle, mas ...

Preço! 💰

DevCycle começa gratuito e escala de acordo com seu negócio. Outras alternativas normalmente não começam gratuitas, e escalam por quantidade de projetos, ou pessoas usando, o que sempre foi muito ruim pra mim. Isso força a gente a entulhar tudo em um projeto, e ter aquela famosa conta compartilhada na empresa. Quem nunca? Risco de segurança? Nada. De boas. Só olha pro lado.

Vamos começar 🏁

1) Crie um projeto React e instale o DevCycle:

# Cria o projeto react-ff
npm create vite@latest react-ff -- --template react

# Entra no projeto
cd react-ff

# Instala o SDK de React do DevCycle
npm i @devcycle/devcycle-react-sdk

# Verifica que o projeto está funcionando
npm run dev

2) Crie um arquivo .env

Na raiz do seu projeto, crie um arquivo .env com um valor temporário. Mais tarde vamos colocar o valor definitivo aqui.

VITE_DVC_SDK_KEY=valor_temporario

3) Adicione uma feature flag ao projeto

No arquivo App.jsx faça as seguintes alterações:

import {
  useVariableValue,
  withDVCProvider
} from "@devcycle/devcycle-react-sdk";

function App() {
  // Busca a variável ainda não criada, usando false como o valor padrão.
  const myFeatureFlag = useVariableValue('my-feature-flag', false);

  return (
    <>
      {/* vai rederizar o falso por enquanto */}
      {myFeatureFlag && <p>My feature flag is on!</p>}
      {!myFeatureFlag && <p>My feature flag is off!</p>}
    </>
  );
}

export default withDVCProvider({
  sdkKey: import.meta.env.VITE_DVC_SDK_KEY
})(App);

4) Configurando o DevCycle e sua feature flag

Registre uma conta no DevCycle. Depois disso, crie uma organização e projeto qualquer (depois você vai poder deletar e recriar a vontade), e uma feature flag do tipo Release com o mesmo nome que usamos antes (my-feature-flag).

Dentro do DevCycle, no menu superior no canto direito, clique no ícone de chave. Você vai ser redirecionado para a página de Keys dos SDK por ambiente. Copie o Client do Development, e substitua valor_temporario no .env por essa sua chave. Se tudo deu certo, você deve ver que a sua feature flag está ativa. Agora você pode voltar pro DevCycle e brincar com ela a vontade.

Nota: Não se esqueça de que você vai precisar fazer essa configuração para os demais ambientes que tiver.

Recapitulando 🔛

Em poucos passos conseguimos ter um projeto com uma feature flag funcionando. Foi menos tempo do que levaríamos pra pensar em como fazer uma solução simples, e ainda é gratuito até seu negócio crescer o suficiente.

Além disso, você vai saber as métricas de uso, poderá saber onde no código está sendo implementado pela plataforma ou pelo CLI, e até fazer uma migração progressiva do sistema que está usando atualmente.

Finalizando 🎉

Espero que esse artigo tenha te ajudado de alguma forma, e nos vemos na próxima \o/

Data Driven Design System com Omlet

Klaus Kazlauskas — Wed, 24 May 2023 12:29:52 +0000

Oie! Eu me chamo Klaus Kazlauskas, sou desenvolvedor a mais de 10 anos, e eu estou esperando por algo como o Omlet esse tempo todo.

Você já esteve em um projeto e quis saber quantas vezes seus componentes são usados, ou onde ele é usado? Já quis saber quantos Buttons diferentes foram criados no seu projeto? Ou até mesmo sentiu uma falta de confiança na hora de atualizar componentes? Então, Omlet resolveu tudo isso pra mim.

O que é o Omlet?

É uma ferramenta, em beta, que está sendo desenvolvida pela equipe do Zeplin, para coletar dados de uso dos componentes de múltiplos projetos. Rodando apenas 3 comandos, você vai saber:

Quantas vezes seu componente foi usado;
Quais dependem dele, e quais são dependências dele;
Quais projetos estão usando os componentes;

Fonte: Site do Omlet

No momento que esse artigo foi criado, a ferramenta ainda está em beta, e só suporta componentes escritos em React.

Primeiros passos com o Omlet

Antes de rodar os comandos, precisamos criar uma conta no https://omlet.dev/ e dar um nome pro nosso ÚNICO workspace. Como a ferramenta está em beta, no momento você só pode ter 1 workspace por conta/e-mail, então de um bom nome ou use um e-mail para testes.

Com o workspace criado, escolha o repositório React que você quer coletar dados dos componentes, e rode os seguintes comandos:

npm i --save-dev @omlet/cli
npx omlet login
npx omlet init

Nas próximas vezes, ou após instalar em outros repositórios, você só vai precisar rodar npx omlet analyze.

Pronto. Após alguns segundos você receberá uma URL para o seu workspace com o scan finalizado, e você terá que escolher a pasta ou projeto que tem os seus componentes principais. Agora você tem acesso instantâneo aos dados de uso dos seus componentes. Depois você poderá automatizar isso com uma configuração de CI.

Aba de análise (Analytics)

Nessa aba você tem acesso instantâneo a uma visão geral dos seus componentes e projetos. São apresentados gráficos como:

Componentes principais vs secundários

Fonte: Site do Omlet

Componentes mais utilizados

Fonte: Site do Omlet

Aba de componentes

Nessa aba você terá acesso a lista de todos os seus componentes de todos os seus projetos, além de poder olhar onde e como seu componente é usado ao clicar nele.

Página de tags

Aqui você pode criar quantas tags você quiser, e adicionar para os projetos ou pastas que quiser. Por exemplo, você pode ter a tag core no projeto da sua biblioteca de componentes, e uma tag de deprecated algumas pastas dessa biblioteca. Assim você consegue trackear a adoção dos novos componentes.

Casos de uso

Agora que você sabe sobre o Omlet, instalou ele, e sabe das páginas, que tal saber mais problemas que ele pode resolver pra você?

Aqui vai uma lista de problemas que o Omlet vai ou já resolveu pra mim:

Usando a página de componentes:
- Achar onde os componentes são utilizados (em segundos)
- Saber quais componentes são inúteis e onde eles são usados
- Descobrir componentes com nome parecidos
Usando tags:
- Saber quais componentes queremos refatorar
- Resolver conflitos de organização ou agrupamento de pastas
Usando dashboards + tags:
- Saber como está a adoção dos componentes
- Saber o progresso da refatoração dos projetos

Esses e mais outros problemas podem ser resolvidos hoje com ele, e o melhor, você não precisa gastar HORAS criando e MANTENDO documentos, listas, gráficos e apresentações. Está tudo disponível para você e sua equipe.

Concluindo

Botando um pouco os pés no chão, vamos relembrar que é uma ferramenta em beta, então espere erros e faltar algumas funções; não é open source, então um dia vão cobrar pra usar; hoje só suporta React, mas tem planos para suportar outras tecnologias.

Dito isso, o Omlet é foda! Ainda acho que o Omlet vai se tornar essencial para quem lida com projetos médios a grandes, ou até mesmo múltiplos pequenos projetos e um design system. Então o futuro preço a ser cobrado deve valer MUITO a pena, principalmente quando comparado com as horas ou dias gastos refatorando coisas que não tem valor, ou pesquisando e trazendo resultados insatisfatórios.

Espero que esse artigo tenha te ajudado. Se gostou, não esqueça de reagir ou compartilhar com seus amigos e colegas, ou seguir se quiser mais artigos como esse.

Não deixe de comentar melhorias ou abrir discussões abaixo!

Um forte abraço e te vejo na próxima \o/

Iniciando um Design System com Storybook 5.3 e Angular

Klaus Kazlauskas — Fri, 31 Jan 2020 11:02:11 +0000

O Storybook 5.3 foi lançado oficialmente há duas semanas e ele trouxe ótimas melhorias. Além de ficar mais fácil de usar e configurar, ele não é mais "só" um explorador de componentes UI. Ele se tornou uma ferramenta incrível para desenvolver um Design System, e eu vou explorar isso com vocês!

Esse artigo é baseado principalmente nos 4 artigos, criados pela equipe do Storybook, sobre esse lançamento. Se quiser ver essas histórias, que são mais curtas e estão separadas, você pode pular direto para Fontes.

Se você não sabe o que é o Storybook, recomendo ler meu artigo anterior, pois também vou usar o projeto dele como base para esse artigo.

Como criar uma biblioteca de componentes com Angular e Storybook

Klaus Kazlauskas ・ Jan 3 '20

#angular #storybook

Índice dos tópicos principais:

Atualizando os pacotes
Configuração declarativa
Geração automática de documentação
Iniciando um Design System com MDX
Storybook focado em Design

Preparação

Na época que esse guia foi preparado, foram usadas as seguintes tecnologias:

tecnologia	versão	instalação
Node.js	11.6.0	como instalar
NPM	6.13.4	Já vem com o Node.js
Angular CLI	8.3.21	como instalar
Storybook	5.3.8	como instalar

Todo o código desse projeto está no GitHub. Então, caso você se perca em qualquer parte, pode fazer uma comparação direta:

klauskpm / angular-storybook

Repositório para ensinar a usar Storybook com Angular.

Atualizando os pacotes

Se você instalou os pacotes do Storybook e agora precisa atualizar eles, não se preocupe. Você só precisa rodar o seguinte comando no seu terminal:

# dentro do seu projeto
npx npm-check-updates '/storybook/' -u && npm install

O npm-check-updates é um pacote que verifica se um pacote precisa atualizar. Nós passamos uma expressão regular para ele achar todos os pacotes que tenham storybook no nome, e a opção -u para atualizar o nosso package.json.

O npx é um comando do Node/npm para executar pacotes sem precisar instalar eles. Ótimo para casos em que não queremos instalar um pacote globalmente porque só vamos usar ele apenas uma vez.

Pode comparar o seu progresso com a tag v2.0 do repositório

Configuração declarativa

O Storybook já tinha uma configuração bem simples, mas tinham alguns pontos que poderiam melhorar, como alguns nomes que não eram claros de acordo com as responsabilidades e a utilização da API do Webpack. Agora que resolveram esses problemas, vamos ver como a ela ficou.

`main.js`

Fonte

O main.js é o arquivo principal de configuração do Storybook e é responsável por tudo que lida com a renderização das nossas histórias. Nesse arquivo vamos declarar, onde devemos buscar as histórias e como identificar elas, quais são os addons da aplicação e as configurações de presets.

Vamos ver como escrevíamos antes e como é hoje.

Antes

.storybook/config.js

import { configure } from '@storybook/angular';

configure([
  require.context('../src', true, /\.stories\.[tj]s$/),
  require.context('../projects', true, /\.stories\.[tj]s$/)
], module);

.storybook/addons.js

import '@storybook/addon-knobs/register';
import '@storybook/addon-actions/register';

Depois

.storybook/main.js

module.exports = {
  stories: [
    '../src/**/*.stories.(ts|js)',
    '../projects/**/*.stories.(ts|js)'
  ],
  addons: [
    '@storybook/addon-knobs',
    '@storybook/addon-actions'
  ]
};

Com isso nós conseguimos matar o config.js e o addons.js do nosso projeto e temos uma configuração bem mais simples de entender. Apesar de nesse exemplo nós termos matado o config.js, nós poderíamos ter outras configurações nele. Essas configurações foram absorvidas pelo preview.js.

`preview.js`

O preview.js cuida do iframe que exibe (preview) a sua história e das configurações globais. É nele que vamos fazer a importação de CSS e polyfill, e configurações de parâmetros e decorators, que era a segunda responsabilidade do config.js.

No nosso caso só vamos configurar o addon knobs, que estava sendo configurado dentro do simple-button/index.stories.ts.

.storybook/preview.js

import { addDecorator } from "@storybook/angular";
import { withKnobs } from "@storybook/addon-knobs";

addDecorator(withKnobs);

`manager.js`

O manager.js cuida da parte gráfica que está em volta dos "previews" das histórias e também a parte dos addons. É nele que vamos adicionar configurações como temas, logo e nome da empresa, e configurações de exibição dos addons.

Vamos criar um tema com a base clara e definir que o nome do nosso Storybook é "Angular Storybook":

.storybook/manager.js

import { create } from '@storybook/theming/create';
import { addons } from "@storybook/addons";

addons.setConfig({
  theme: create({
    base: 'light',
    brandTitle: 'Angular Storybook'
  })
});

E vamos ter o seguinte resultado:

O layout continua o mesmo, mas, em vez da logo do Storybook, está aparecendo o nome do nosso projeto definido no tema.

Se quiser saber mais sobre a parte de tema, você pode ver a documentação oficial sobre criação de temas.

Separadores de hierarquia

Antes do 5.3, o Storybook aceitava vários tipos de separadores de hierarquia, como |, \ e .. mas agora ele força a hierarquia a ser definida sempre com /. Então, uma história que tinha esse título UI|Buttons & Indicators/Button ficaria assim UI/Buttons & Indicators/Button.

Vamos revisitar o nosso simple-button/index.stories.ts e substituir o título da história respeitando a nova hierarquia:

projects/storybook-ui/src/lib/simple-button/index.stories.ts

import { SimpleButtonComponent } from './simple-button.component';
import { text } from '@storybook/addon-knobs';
import { moduleMetadata } from '@storybook/angular';
import { action } from '@storybook/addon-actions';

export default {
  title: 'UI / Button',
  decorators: [
    moduleMetadata({declarations: [SimpleButtonComponent]})
  ],
};

export const withDefaultValues = () => ({
  component: SimpleButtonComponent
});

export const withText = () => {
  return {
    template: `
        <ui-simple-button
          [text]="text"
          (click)="click($event)"
        ></ui-simple-button>
    `,
    props: {
      text: text('Text', 'Ola'),
      click: action('Clicou')
    }
  };
};

Fazendo a atualização em massa

Fazer essa alteração na mão para apenas uma história é simples, mas quando começam a ser várias e com vários níveis, isso se torna trabalhoso. Felizmente, a equipe do Storybook fez um script para atualizar isso de forma automática. Você só precisa rodar o seguinte comando:

# dentro do seu projeto
npx -p @storybook/cli sb migrate upgrade-hierarchy-separators --glob="*.stories.(ts|js)"

Perdemos o root!

Com essa atualização nós perdemos o root/raiz das nossas histórias. O root aparecia como um texto em cima das nossas histórias. No nosso caso, era o UI, e tinhamos como pasta o Button. Sem o root, o UI se torna uma pasta como o Button.

Para recuperar essa aparência de root, nós precisamos adicionar o seguinte código no .storybook/preview.js:

.storybook/preview.js

addParameters({ 
  options: {
    showRoots: true,
  },
});

Migração

Tanto a parte do antigo config.js quanto os antigos separadores vão ser suportados até a versão 6.0.0 do Storybook. Felizmente, esse artigo já é suficiente para te preparar para essa versão, mas, caso queira consultar uma fonte oficial, a equipe do Storybook também preparou um guia de migração do 5.2 para o 5.3 para facilitar todo esse processo.

Saber mais sobre

Se quiser saber mais detalhes sobre a parte da configuração declarativa, você pode ver o artigo oficial do Storybook:

Declarative Storybook configuration | by Norbert de Langen | Storybook | Medium

Norbert de Langen ・ Jan 27, 2020 ・
Medium

Pode comparar o seu progresso com a tag 2.1 do repositório

Geração automática de documentação

O Storybook agora da suporte ao DocsPage para geração automática de documentação, e ao MDX para documentações mais longas e customizadas - vamos falar dele mais tarde.

Fonte

Configurando o DocsPage

Para usar o DocsPage só preciamos instalar umas dependências, adicionar poucas configurações, e a documentação está pronta. Parece mágica, mas é melhor!

Instale as dependências

Primeiro nós vamos instalar o @storybook/addon-docs (responsável pela geração das páginas) e o @compodoc/compodoc (gerador de documentação do de projetos do Angular).

# dentro do seu projeto
npm install --save-dev @storybook/addon-docs @compodoc/compodoc

Mais tarde vou detalhar a importância do compodoc.

Adicione os scripts de geração

Vamos criar o script docs:storybook que vai ser responsável por gerar a documentação do nosso projeto, e vamos adicionar esse script antes da execução do storybook e do build-storybook.

package.json

{
  ...,
  "scripts": {
    "docs:storybook": "compodoc -p .storybook/tsconfig.json -e json -d .",
    "storybook": "npm run docs:storybook && start-storybook -p 6006",
    "build-storybook": "npm run docs:storybook && build-storybook"
  }
}

O comando que configuramos vai gerar um arquivo JSON chamado documentation.json e vamos passar essas informações para o @storybook/addon-docs.

⚠️ Na documentação é recomendado usar o tsconfig.json do projeto principal em vez do .storybook/tsconfig.json, mas como estamos usando o compodoc para o Storybook, na MINHA OPINIÃO faz mais sentido usar o do Storybook. Sinta-se livre para discordar e opinar!

Infelizmente, a documentação não atualiza automaticamente ao mudar o componente. Precisamos regerar o documentation.json sempre que quisermos as informações mais novas. Felizmente já tem uma issue aberta sobre isso.

Explicando o `compodoc`

Explicando um pouco o comando que acabamos de configurar, nós passamos as seguintes opções:

-p ou --tsconfig para definir qual tsconfig vai ser usado
-e ou --exportFormat para definir o formato que vai ser exportado
-d ou --output para definir a pasta em que vai ser exportada a documentação

Se usássemos as opções padrões do compodoc e gerássemos a documentação com compodoc -p .storybook/tsconfig.json, seria gerada a pasta documentation com páginas HTML com uma documentação completa do projeto.

Fonte

Configure o `@storybook/addon-docs`

Como todos os outros addons nós precisamos adicionar ele no .storybook/main.js para ele ser carregado:

.storybook/main.js

module.exports = {
  ...
  addons: [
    ...,
    '@storybook/addon-docs',
  ]
};

Além disso, precisamos alimentar ele com o documentation.json gerado pelo compodoc. Vamos adicionar o seguinte no .storybook/preview.js:

.storybook/preview.js

import { setCompodocJson } from "@storybook/addon-docs/dist/frameworks/angular";

import docJson from '../documentation';

setCompodocJson(docJson);

E por último, não podemos esquecer de adicionar a propriedade component na história do nosso componente. É com ela que será identificado o componente e vinculado a tabela de propriedades geradas pelo compodoc:

projects/storybook-ui/src/lib/simple-button/index.stories.ts

export default {
  title: 'UI / Button',
  component: SimpleButtonComponent, // Adicionado aqui
  decorators: [
    moduleMetadata({declarations: [SimpleButtonComponent]})
  ],
};

Adicione uns enfeites (opcional)

Apenas para ver como a tabela de propriedades é gerada pelo compodoc, vamos adicionar o seguinte no simple-button/index.stories.ts:

projects/storybook-ui/src/lib/simple-button/simple-button.component.ts

/**
 * ViewChild que está vinculada a nada
 */
@ViewChild('empty', { static: false })
empty: TemplateRef<any>;

/**
 * Output fake
 */
@Output()
clicked = new EventEmitter();

/**
 * Input que define o texto apresentado no botão
 */
@Input()
text = 'clique aqui';

/**
 * Método simples e público
 * @return void
 */
public simpleMethod(): void {}

/**
 * Método complexo e privado
 * @return string
 */
private complexMethod(num1: number, num2: number): string {
  return '';
}

E também podemos controlar o tamanho do preview das histórias da documentação adicionando uma configuração no .storybook/preview.js:

.storybook/preview.js

addParameters({
  ...,
  docs: {
    iframeHeight: 60
  }
});

Resultado

Agora, quando rodarmos o comando npm run storybook, devemos ver o seguinte:

🎉 Storybook com documentação gerada 🎉

Saber mais sobre

Se quiser saber mais detalhes sobre geração de documentação, você pode ler o guia oficial para o Angular, ou o artigo oficial do Storybook:

Storybook Docs for new frameworks | by Michael Shilman | Storybook | Medium

Michael Shilman ・ Jan 14, 2020 ・
Medium

Pode comparar o seu progresso com a tag v2.2 do repositório

Iniciando um Design System com MDX

MDX é a mistura de Markdown (MD) e JSX (sintaxe do React para escrita de templates). Com o MDX, o Storybook nos da a liberdade de melhorar ou substituir as documentações geradas automaticamente, e muito mais!

Fonte

Com o MDX podemos escrever histórias apenas com MDX ou misturar as histórias em CSF (Component Story Format) com MDX. Também podemos escrever um MDX de documentação sem histórias, como design tokens e introdução ao design system. Segue abaixo o exemplo de um projeto:

Site | GitHub

Como escrevemos em MDX

Fonte

Olhando a imagem acima, podemos ver o #Badge e o Lets define... e isso faz parte da sintaxe do Markdown. Enquanto isso o <Badge> que é um componente feito em React, e o <Meta>, <Story> e <Preview> que fazem parte do addon-docs, usam a sintaxe do JSX. Isso quer dizer que, quando quisermos adicionar textos e formatações nós vamos usar o MD (Markdown), e quando quisermos adicionar algum layout ou funcionalidade diferente, vamos usar componentes em React com JSX. Segue abaixo o que seria o resultado do MDX apresentado anteriormente:

Fonte

O resultado dessa combinação é uma sintaxe muito mais simples. Ela é tão simples, e mais afastada da programação, que se torna fácil para que pessoas sem conhecimento da nossa linguagem de programação possam contribuir com a documentação do nosso Design System.

Fonte | Site | GitHub | Componentes de Auxílio

Configurando o MDX

Para fazer o MDX rodar é bem simples. Nós precisamos instalar algumas dependências e fazer nosso sistema encontrar os arquivos MDX.

Instale as dependências

O MDX precisa do DocsPage e do React (JSX). Como já fizemos as instalações pro DocsPage anteiormente, vamos só fazer as instalações necessárias do React.

# dentro do seu projeto
npm install --save-dev react react-is babel-loader

Altere o `main.js`

O nosso .storybook/main.js já está configurado para procurar por histórias que tenham as extensões ts ou js. Então só precisamos adicionar a extensão mdx:

module.exports = {
  stories: [
    '../src/**/*.stories.(ts|js|mdx)',
    '../projects/**/*.stories.(ts|js|mdx)'
  ],
  addons: [
    '@storybook/addon-docs',
    '@storybook/addon-knobs',
    '@storybook/addon-actions'
  ]
};

Criando um arquivo `MDX`

Por enquanto vamos criar só um arquivo de ilustração. Só precisa copiar e colar que mais tarde vou explicar a sintaxe. Dentro de projects/storybook-ui/src/lib/ vamos criar o arquivo design-system/getting-started.stories.mdx para introduzir as pessoas ao nosso design system:

projects/storybook-ui/src/lib/design-system/getting-started.stories.mdx

import { Meta } from '@storybook/addon-docs/blocks';

<Meta title='Design System / Introdução' />

# Introdução

Olá pessoa! Seja bem vinda ao meu Design System

Veja o resultado

Agora, quando você rodar o comando npm run storybook, você deve ver algo como o que está abaixo:

Criando histórias com MDX

Nós configuramos o DocsPage e o MDX, e vimos ambos em ação. Agora, nós precisamos dar o próximo passo e entender como criar histórias em MDX. Para isso, devemos saber quais ferramentas temos.

Blocos do `@storybook/addon-docs`

O Storybook nos dá vários blocos para montarmos nossas histórias, e os 4 blocos principais são:

Meta para definir título, decorators e parameters (assim como o que definimos no export default no CSF)
Props para exibir a tabela de propriedades do componente
Story para criar a história do componente e exibir ela na documentação
Preview para exibir a história do componente em volta de um bloco de exibição

Existem outros blocos além desses, como o ColorPalette para design tokens, mas esses 4 são os principais e devem aparecer em todas as histórias que fizermos com MDX. Além disso, também podemos criar os nossos próprios blocos usando o React.

Estilos de escrita com MDX

Diferente do React e do Vue, no Storybook o Angular não tem a habilidade de escrever histórias inline. Felizmente, temos outras abordagens:

histórias puras em MDX
histórias em CSF com documentação em MDX
histórias em CSF definindo o MDX arbitrariamente (MDX não podendo definir histórias, só referênciando).

Não irei abordar o último estilo de escrita com MDX (histórias em CSF definindo o MDX arbitrariamente), pois eu não consegui fazer ele funcionar. Continuarei buscando soluções e atualizarei esse artigo caso consiga.

Histórias puras em MDX

Essa abordagem é ótima para documentações, como o getting-started.stories.mdx, e também para componentes simples. Como eles não precisam de muita configuração, e no máximo tem alguns inputs e outputs simples, não precisamos de um arquivo de lógica. Segue abaixo um exemplo:

index.stories.mdx

import { Meta, Story, Props, Preview } from '@storybook/addon-docs/blocks';
import { moduleMetadata, addDecorator } from '@storybook/angular';
import { SimpleButtonComponent } from '../simple-button.component';

<Meta
  title='UI / Button'
  component={SimpleButtonComponent}
  decorators={[moduleMetadata({ declarations: [SimpleButtonComponent] })]}
/>

# SimpleButton Component

Uma descrição simples em **markdown**.
Exibindo o `SimpleButtonComponent` usando o `Story`.

<Story name='basic' height='60px'>{{
  component: SimpleButtonComponent,
  props: {},
}}</Story>

## Props

A tabela de propriedades é exibida com usando o `Props`.

<Props of={SimpleButtonComponent} />


## Stories

Fazendo preview da história com `<Preview>`.

<Preview>
  <Story name="Basic Preview">{{
    component: SimpleButtonComponent,
    props: {},
  }}</Story>
</Preview>

Histórias em CSF com documentação em MDX

As vezes nós temos componentes mais complexos, ou com dados mais longos, e queremos deixar a parte da documentação mais simples possível. Para esses casos nós vamos ter dois arquivos, um CSF (.ts ou .js) e um MDX (.mdx). No CSF vamos deixar as histórias e lógicas, e no MDX vamos deixar a documentação e aplicaremos as histórias nos devidos lugares. Segue abaixo um exemplo:

stories.ts

import { action } from '@storybook/addon-actions';
import { text } from '@storybook/addon-knobs';
import { SimpleButtonComponent } from '../simple-button.component';

export const withDefaultValues = () => ({
  component: SimpleButtonComponent
});

export const withText = () => {
  return {
    template: `
        <ui-simple-button
          [text]="text"
          (click)="click($event)"
        ></ui-simple-button>
    `,
    props: {
      text: text('Text', 'Ola'),
      click: action('Clicou')
    }
  };
};

index.stories.mdx

import { Meta, Story, Props, Preview } from '@storybook/addon-docs/blocks';
import { moduleMetadata, addDecorator } from '@storybook/angular';
import { SimpleButtonComponent } from '../simple-button.component';
import * as stories from './stories.ts';

<Meta
  title='UI / Button'
  component={SimpleButtonComponent}
  decorators={[moduleMetadata({ declarations: [SimpleButtonComponent] })]}
/>

# SimpleButton Component

Uma descrição simples em **markdown**.
Exibindo o `SimpleButtonComponent` usando o `CSF` + `MDX`.

<Story name='basic' height='60px'>{stories.withDefaultValues()}</Story>

## Props

A tabela de propriedades é exibida com usando o `Props`.

<Props of={SimpleButtonComponent} />


## Stories

Usando histórias criadas em CSF no MDX

<Preview>
  <Story name="With Text">{stories.withText()}</Story>
</Preview>

Vamos atualizar nossa história

Vendo as estratégias acima, podemos afirmar que nosso componente só precisa de um arquivo MDX porque ele é bem simples, mas, apenas por questão de demonstração, vamos usar os dois estilos ao mesmo tempo. Vamos pegar o nosso simple-button/index.stories.ts e começar a criar nossa nova documentação dele. Vamos seguir os seguintes passos:

Crie a pasta stories dentro de projects/storybook-ui/src/lib/simple-button
Renomei o index.stories.ts para stories.ts e mova ele para dentro de stories
Crie o arquivo index.stories.mdx dentro stories

Nós renomeamos o arquivo para não haver um possível problema de carregamento das histórias, e movemos os dois arquivos para uma outra pasta apenas por questão de organização.

Agora, vamos aplicar as mudanças no conteúdo dos arquivos:

stories.ts

import { action } from '@storybook/addon-actions';
import { text } from '@storybook/addon-knobs';
import { SimpleButtonComponent } from '../simple-button.component';

export const withDefaultValues = () => ({
  component: SimpleButtonComponent
});

export const withText = () => {
  return {
    template: `
        <ui-simple-button
          [text]="text"
          (click)="click($event)"
        ></ui-simple-button>
    `,
    props: {
      text: text('Text', 'Ola'),
      click: action('Clicou')
    }
  };
};

index.stories.mdx

import { Meta, Story, Props, Preview } from '@storybook/addon-docs/blocks';
import { moduleMetadata, addDecorator } from '@storybook/angular';
import { SimpleButtonComponent } from '../simple-button.component';
import * as stories from './stories.ts';

<Meta
  title='UI / SimpleButton'
  component={SimpleButtonComponent}
  decorators={[moduleMetadata({ declarations: [SimpleButtonComponent] })]}
/>

# SimpleButton Component

Uma descrição simples em **markdown**.
Exibindo o `SimpleButtonComponent` usando o `Story`.

<Story name='simples' height='60px'>{{
  component: SimpleButtonComponent,
  props: {},
}}</Story>

## Props

A tabela de propriedades é exibida com usando o `Props`.

<Props of={SimpleButtonComponent} />


## Stories

Usando histórias criadas em CSF no MDX

<Preview>
  <Story name="com valores default">{stories.withDefaultValues()}</Story>
</Preview>

<Preview>
  <Story name="com texto diferente">{stories.withText()}</Story>
</Preview>

O resultado resultado é esse:

Saber mais sobre

Se quiser saber mais detalhes sobre documentação rica com MDX, você pode ler o artigo oficial do Storybook:

Rich docs with Storybook MDX. Components & documentation in harmony… | by Michael Shilman | Storybook | Medium

Michael Shilman ・ Jan 14, 2020 ・
Medium

Além disso, também tem esses links super importantes com documentações e exemplos:

Antes de ir para a próxima sessão, se você já tem várias histórias criadas no Storybook no estilo do storiesOf ou CSF e quer mudar todas, ou algumas, para outro estilo, você pode dar uma olhada no codemod. Ele tem scripts para mudar, em massa, as histórias de estilo e isso pode te poupar muito tempo.

Pode comparar o seu progresso com a tag v2.3 do repositório

Storybook focado em Design

Quando lidamos com qualquer organização de um projeto, a parte mais difícil é a comunicação. Seja a falta ou o mau uso dela. Para resolver esse problema, em relação aos aspectos de Design de um sistema, existe o Design System.

Apesar de o Design System ser uma ótima solução, cada equipe tem um conjunto de ferramentas e elas vivem em seus universos isolados. Isso torna o trabalho de manter um Design System algo, um tanto que, trabalhoso.

Por esse motivo, eu fico muito feliz quando vejo o time do Storybook exibindo tantas integrações com essas essas ferramentas.

Fonte

Figma addon
As mudanças de Design vão aparecer automaticamente no Storybook
Abstract addon (para Sketch e Adobe XD)
Abre um painel nas histórias do Storybook, onde você vê os layers e containers do Abstract
InVision Design System Manager
O DSM permite ver os componentes do Storybook, no app do DSM, junto dos designs extraídos do Sketch
Zeplin
Linka e mostra uma minidocumentação dos componentes do Storybook direto com o app do Zeplin
Zeroheight
O addon leva os componentes do Storybook para serem exibidos junto com os designs de outras ferramentas, como Sketch, Figma, ou Adobe XD
Story2sketch for Sketch
Converte histórias do Storybook em símbolos do Sketch
Design Token
Transforma e exibe design tokens identificados em um painel no Storybook

Fonte

São integrações para a equipe de Design ver os nossos componentes e usar eles nos próximos designs, ou para nós vermos os designs deles e compararmos cores, tamanhos e fontes. O objetivo é todos terem uma única fonte de verdade sobre os elementos de design e facilitar a manutenção e evolução do Design System

Saber mais sobre

Se quiser saber mais detalhes sobre Storybook para Design, você pode ler o artigo oficial do Storybook:

Storybook for design. How to integrate your favorite design… | by Dominic Nguyen | Storybook | Medium

Dominic Nguyen ・ Sep 24, 2020 ・
Medium

Conclusão

Além de facilitar a utilização e configuração, também adicionaram vários modos de criação de documentação (DocsPage e MDX) e várias integrações com as ferramentas de Design. O Storybook tem evoluído muito, e vai continuar evoluindo, para se tornar a ferramenta para criações de Design System.

Eu aprendi muito enquanto fazia esse artigo e espero que ele ajude você também.

Um forte abraço e até a próxima! 😬

Fontes

A base desse artigo foram os 4 artigos sobre o lançamento da nova versão do Storybook. Segue abaixo os links:

Além desse artigos, também tiveram esses outros links:

Como gerar CHANGELOG automaticamente

Klaus Kazlauskas — Fri, 17 Jan 2020 12:10:40 +0000

Oie! Se você já usou bibliotecas, ou viu repositórios open-source, você já deve ter visto um arquivo chamado CHANGELOG.md. Até dá pra fazer ele manualmente, mas...

Você luta contra muitos fatores e perde muito tempo. Além disso, é muito simples fazer de forma automática. Só precisamos:

Definir um padrão para os nossos commits
Usar pacotes para auxiliar nesses padrões
Usar um pacote para gerar o CHANGELOG

Então, vamos começar a gerar nosso CHANGELOG.

Preparação

Na época que esse guia foi preparado, foram usadas as seguintes tecnologias:

tecnologia	versão	instalação
Node.js	11.6.0	como instalar
NPM	6.13.4	Já vem com o Node.js

Todo o código desse projeto está no GitHub, então, caso você se perca em qualquer parte, pode fazer uma comparação direta. Além disso, todos os passos desse artigo estão lá de forma resumida:

klauskpm / changelog-cicd

Repositório para ensinar a criar CHANGELOG automaticamente

changelog-cicd

Repositório com passo-a-passo de como gerar um CHANGELOG automaticamente.

Esse passo-a-passo é a versão muito resumida do artigo: Como gerar CHANGELOG automaticamente

Gerando um CHANGELOG automaticamente

1) Instale as dependências

npm install --global commitizen

# dentro do seu projeto
npm install --save-dev husky @commitlint/cli @commitlint/config-conventional standard-version

2) Configure o commitizen

# dentro do seu projeto
commitizen init cz-conventional-changelog --save-dev --save-exact

3) Crie o arquivo `commitlint.config.js`

module.exports = {
    extends: ['@commitlint/config-conventional']
};

4) Altere o seu `package.json`

{
  ...,
  // opcional
  "repository": {
    "url": "git@gitlab.com:meu-usuario/meu-repo.git"
  },
  ...,
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "scripts": {
    "release": "standard-version"
  }
}

5) Crie o arquivo `.versionrc`

{
  "types": [
    {"type": "feat", "section": "Funcionalidades"}
    {"type": "fix"

…

View on GitHub

Padronizando as mensagens de commit

O padrão que vamos seguir para as mensagens é o conventional commit specification(especificação convencional de commit). Esse padrão é escrito da seguinte forma:



<tipo>[(escopo opcional)]: <descrição>

[corpo opcional]

[rodapé opcional]

campo	obrigatório	descrição
tipo	✅	Tipo do commit que vai ser feito. Verificar lista de tipos permitidos.
escopo	❌	Arquivo, domínio, ou módulo que aquele commit se refere
descrição	✅	Uma descrição curta sobre o commit
corpo	❌	Uma descrição maior, caso não consiga explicar com clareza tudo o que tem no commit
rodapé	❌	Fechamento de tarefas e/ou informação sobre breaking changes

Lista de tipos permitidos

feat: Uma funcionalidade
fix: Um ajuste de erro/bug
docs: Modificação na documentação
style: Mudança de estilo (ponto, vírgula, indentação)
refactor: Mudança de código que não adiciona funcionalidade ou arruma um erro
perf: Mudança que altera performance
test: Novos testes ou correção de antigos
build: Mudanças que afetam o build ou dependências exeternas (gulp, npm)
ci: Mudanças na configuração da Integração Contínua (Travis, Circle)
chore: Outras mudanças que não são nos arquivos de src ou test
revert: Reversão de um commit

Exemplos de commit



feat(cadastro): adiciona integração com Gugou Sign-in



fix(pagamento): muda a chave do RecebaSeguro

A chave que estava sendo usada era de desenvolvimento,
mas acabou sendo enviada para produção

Fecha a tarefa #457



refactor(produto): remove o método #adicionarAoCarrinho

O método já tinha sido depreciado e agora foi removido

BREAKING CHANGE: o método públic #adicionarAoCarrinho foi removido

Facilitando a padronização

Apesar da padronização facilitar a automatização, ela pode ser muita coisa pra gravar de primeira. Então, para facilitar a aplicação desse padrão, nós vamos usar o Commitizen e o Commitlint.

Commitlint

O commitlint vai verificar se nossos commits estão seguindo o Conventional Commit Specification. Ele vai fazer isso com a ajuda do husky, que irá disparar o commitlint toda vez que for feito um commit.

1) Instale as dependências



# dentro do seu projeto
npm install --save-dev husky @commitlint/cli @commitlint/config-conventional

2) Crie o commitlint.config.js



module.exports = {
    extends: ['@commitlint/config-conventional']
};

3) Configure o `husky` no package.json



{
  ...,
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
}

4) Teste para ver se está funcionando (opcional)

A configuração está pronta e já deve estar funcionando. Se quiser, pode fazer uma adição no seu projeto e commitar como teste para quebrar. Você deve receber um erro explicando o que está faltando no commit.

Commitizen

Agora que temos algo para verificar nossos commits, precisamos fazer eles de uma maneira mais fácil. Com o commitizen, nós vamos commitar usando o comando git cz, que vai fazer perguntas passo-a-passo até ter o commit final.

1) Instale e configure o `commitizen`



npm install --global commitizen

# dentro do seu projeto
commitizen init cz-conventional-changelog --save-dev --save-exact

2) Teste para ver se está funcionando

Faça uma pequena alteração, adicione ela com git add . e faça um git cz.

Automatizando o CHANGELOG

Agora que nós temos os commits seguindo um padrão, podemos gerar o nosso arquivo CHANGELOG. Os dois pacotes mais utilizados para fazer essa tarefa hoje, são o semantic-release e o standard-version. Vamos seguir com o standard-version pela facilidade do uso.

`standard-version`

Esse pacote vai ser responsável por analisar nossos commits, gerar uma nova versão pro projeto e gerar o CHANGELOG.

1) Instale o `standard-version`



npm install --save-dev standard-version

2) Altere seu `package.json`



{
  "scripts": {
    "release": "standard-version"
  }
}

3) Faça seu primeiro release

Agora que tudo está configurado, commite essas alterações e execute o seguinte comando:



npm run release -- --first-release

O npm run release executa as seguintes etapas:

Modifica a versão do seu package.json

Usa o conventional-changelog para criar/atualizar o CHANGELOG.md

Commita o package.json e o CHANGELOG.md

Gera uma nova tag

A diferença dele para o --first-release, é que o --first-release ignora o passo 1.

🎉 CHANGELOG gerado 🎉

Pode comparar o seu progresso com a tag v1.0.0 do repositório

Explorando o CHANGELOG

Agora que temos tudo, vamos entender como o CHANGELOG é gerado e o que podemos fazer com ele.

Se você for no repositório na v2.1.0, você verá que foram criados vários commits e versões. Olhando essas versões criadas, podemos observar que:

Uma feat representa um minor (X.1.X) do SemVer;
Um fix representa um patch (X.X.1) do SemVer;
Uma BREAKING CHANGE representa um major (1.X.X) do SemVer;
Só aumenta um número por vez. 3 feats aumentam o mesmo que 1;
O maior número é que manda. Se tem feat, não importa o fix;
Só aparecem os commits com feat e fix;
Todos os links estão apontando para o repositório do GitHub;

Tirando os dois últimos pontos, o resto são regras do próprio SemVer (Semantic Versioning), que é quem dita as regras do versionamento (major.minor.patch).

Esses dois últimos pontos ganharam destaque porque eles são muito interessantes. Fazendo uma reflexão, parece que você teria que fazer uma solução própria caso quisesse exibir commits de outros tipos ou se quisesse usar o GitLab. Felizmente, o standard-version tem uma solução bem prática pra isso. Você só precisa passar um arquivo de configuração.

Configurando a geração do CHANGELOG

Podemos passar a configuração pro standard-version de diversas formas, mas vamos focar no .versionrc

Esse arquivo segue a especificação de configuração do conventional changelog. Então, se quiser exibir um outro tipo de commit, botar em português, e usar o GitLab:

1) Crie o arquivo `.versionrc`

Aqui nós estamos adicionando o tipo perf ao CHANGELOG.md, ao mesmo tempo que estamos também definindo os nomes das sessões em português. Por último, estamos adicionando o [skip ci] na mensagem de commit que é gerada pelo standard-version. Isso vai ser útil no futuro.



{
    "types": [
        {"type": "feat", "section": "Funcionalidades"},
        {"type": "fix", "section": "Errors Corrigidos"},
        {"type": "chore", "hidden": true},
        {"type": "docs", "hidden": true},
        {"type": "style", "hidden": true},
        {"type": "refactor", "hidden": true},
        {"type": "perf", "section": "Melhorias de Performance"},
        {"type": "test", "hidden": true}
    ],
    "releaseCommitMessageFormat": "chore(release): {{currentTag}} [skip ci]"
}

2) Altere o `package.json` (Opcional: GitLab)

Se quiser mesmo usar outro repositório, é bem provável que você só precise adicionar o repository.url no seu package.json. O standard-version usa essa URL para definir as URLs do CHANGELOG:



{
  ...,
  "repository": {
    "url": "git@gitlab.com:meu-usuario/meu-repo.git"
  }
}

Se tiver problema nas URLs que foram geradas no seu CHANGELOG.md, você pode adicionar uma configuração customizada para o seguintes campos no seu .versionrc: commitUrlFormat, compareUrlFormat e issueUrlFormat.

Pode comparar o seu progresso com a tag v2.1.1 do repositório

Automatizando a automatização com integração contínua

O nosso CHANGELOG já é gerado graças ao standard-version, mas ainda precisamos rodar o script de forma manual. O ideal é que isso aconteça sempre que o código atinja a versão final / produção. Para isso, vamos usar o GitHub Actions como nossa ferramenta de integração contínua (CI - Continuous Integration).

No repositório do GitHub, na aba Ações/Actions, vamos criar um workflow de Node.js.

E esse é o arquivo que é gerado por padrão nesse workflow, mas não vamos usa-lo:



# nome do processo
name: Node CI

# o processo roda quando tiver um push
on: [push]

jobs:
  build:

    # roda o build no ubuntu
    runs-on: ubuntu-latest

    strategy:
      # o processo vai executar uma vez para cada configuração do node
      matrix:
        node-version: [8.x, 10.x, 12.x]

    steps:
    # esse passo pega uma cópia dos seu repositório
    - uses: actions/checkout@v1

    # esse passo instala a versão do node
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}

    # esse passo faz a instalação das dependências, roda o build e o teste
    - name: npm install, build, and test
      run: |
        npm ci
        npm run build --if-present
        npm test
      env:
        CI: true

Nós vamos usar esse arquivo como base para construir o nosso próprio. Se olhar bem, nós não precisamos realizar um teste, criar uma build ou muito menos rodar em várias versões do node, mas precisamos gerar o CHANGELOG e ele precisa de permissões para commitar e pushar no GitHub.

Além disso, tem um ponto que precisamos prestar muita atenção. Como o nosso processo de automatização gera um commit e roda a cada push, nós vamos criar um loop infinito. Felizmente, eu já passei 1 dia resolvendo isso, e depois de 50 commits disparados automaticamente, achei a solução.

Nos outros sistemas de integração contínua (CI) se fizermos um commit com skip ci - se lembra do .versionrc? - esse commit é automaticamente ignorado. Pena que não funciona assim no GitHub. Felizmente, a internet é um lugar maravilhoso e as pessoas conseguiram desenvolver uma solução para isso.

Juntando os fatores que precisávamos para gerar o CHANGELOG.md e aplicando essa solução que previne o loop, temos o seguinte arquivo:

.github/workflows/gerador-de-changelog.yml



name: Gerador de CHANGELOG

# só executa no push de commit da branch master
on:
  push:
    branches:
      - master

jobs:
  build:
    # só deixa executar se o último commit não conter 'skip ci' na mensagem
    if: "!contains(github.event.head_commit.message, 'skip ci')"

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1

    # configura o GITHUB_TOKEN
    # https://help.github.com/en/actions/automating-your-workflow-with-github-actions/authenticating-with-the-github_token
    - name: Configura o GitHub token
      uses: fregante/setup-git-token@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        name: "Gerador de changelog"
        email: "changelog@users.noreply.github.com"

    # instala a versão 11.x do Node.js
    - name: Instala o Node.js 11.x
      uses: actions/setup-node@v1
      with:
        node-version: 11.x

    # instala as dependências, vai para a master
    # executa o standard-version, e envia o commit e tag
    - name: Gera o CHANGELOG
      run: |
        npm ci
        git checkout master
        npm run release
        git push origin master --follow-tags

Se quiser saber mais sobre como configurar um workflow, como funciona a sintaxe do workflow do GitHub Actions e o que é o GITHUB_TOKEN, sugiro seguir esses links.

Pronto! Agora nossa automatização está completa!

Pode comparar o seu progresso com a tag v2.1.2 do repositório

Última graça

Por último, só para fazer uma graça, podemos adicionar um status badge (distintivo/indicador de status) para o nosso build. Isso é uma imagem que indica se o build passou ou não. Podemos adicionar isso no nosso README.md seguindo esse padrão de URL:



URL 
![](https://github.com/<CONTA>/<REPOSITORIO>/workflows/<NOME_WORKFLOW>/badge.svg)

Exemplo do meu repositório:
![](https://github.com/klauskpm/changelog-cicd/workflows/Gerador%20de%20CHANGELOG/badge.svg)

Sendo klauskpm meu usuário, changelog-cicd o repositório que estou usando, e Gerador de CHANGELOG o nome do workflow, não o do arquivo, com %20 em vez de espaços.

Assim que sua badge será exibida no seu README.md:

Pode comparar o seu progresso com a tag v2.1.3 do repositório

Conclusão

Com esse artigo nós:

Melhoramos a qualidade dos commits
Automatizamos a geração de CHANGELOG e subida de versão
Fizemos integração contínua com GitHub Actions

Caso algo tenha dado errado, pode sempre consultar o repositório com a versão final e um passo-a-passo super resumido desse artigo.

klauskpm / changelog-cicd

Repositório para ensinar a criar CHANGELOG automaticamente

changelog-cicd

Repositório com passo-a-passo de como gerar um CHANGELOG automaticamente.

Esse passo-a-passo é a versão muito resumida do artigo: Como gerar CHANGELOG automaticamente

Gerando um CHANGELOG automaticamente

1) Instale as dependências

npm install --global commitizen

# dentro do seu projeto
npm install --save-dev husky @commitlint/cli @commitlint/config-conventional standard-version

2) Configure o commitizen

# dentro do seu projeto
commitizen init cz-conventional-changelog --save-dev --save-exact

3) Crie o arquivo `commitlint.config.js`

module.exports = {
    extends: ['@commitlint/config-conventional']
};

4) Altere o seu `package.json`

{
  ...,
  // opcional
  "repository": {
    "url": "git@gitlab.com:meu-usuario/meu-repo.git"
  },
  ...,
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "scripts": {
    "release": "standard-version"
  }
}

5) Crie o arquivo `.versionrc`

{
  "types": [
    {"type": "feat", "section": "Funcionalidades"}
    {"type": "fix"

…

View on GitHub

Não deixe de me seguir caso queira receber mais artigos como esse, e compartilhar com seus colegas caso tenha ❤️. Não deixe de comentar se tiver algo que acha que eu deva mudar no artigo.

Um forte abraço e te vejo na próxima 😬

Como criar uma biblioteca de componentes com Angular e Storybook

Klaus Kazlauskas — Fri, 03 Jan 2020 12:10:42 +0000

Se você já tentou criar uma biblioteca de componentes pro seu sistema, você com toda certeza já alterou um componente que quebrou várias páginas e quando te perguntaram quem foi...

Pra eliminar esse e outros problemas, como não saber se um componente existe, como funciona ou em que página você pode ver um exemplo dele funcionando; existe o Storybook.

O Storybook se denomina como "Um explorador de componentes UI para desenvolvedores front-end". Isso quer dizer que ele serve para gerar várias histórias dos nossos componentes, assim como a documentação deles, para facilitar a exploração visual dos nossos componentes.

Então, vamos criar passo-a-passo essa biblioteca de componentes.

Preparação

Na época que esse guia foi preparado, foram usadas as seguintes tecnologias:

tecnologia	versão	instalação
Node.js	11.6.0	como instalar
NPM	6.13.4	Já vem com o Node.js
Angular CLI	8.3.21	como instalar

Todo o código desse projeto está no GitHub, então, caso você se perca em qualquer parte, pode fazer uma comparação direta:

klauskpm / angular-storybook

Repositório para ensinar a usar Storybook com Angular.

⚠️ Caso você já saiba gerar uma biblioteca, você pode pular para a sessão Instalando o Storybook ⚠️

Gerando o projeto

Usando o Angular CLI, vamos criar um projeto chamado angular-storybook e uma biblioteca chamada storybook-ui:

ng new angular-storybook

# dentro do projeto angular-storybook
ng g lib storybook-ui --prefix ui # versão curta de ng generate library

Já temos o projeto para usar nossos componentes, e temos a biblioteca onde vamos desenvolver eles. A biblioteca já vem com um componente pronto, mas não vamos usar ele. Então, vamos até a pasta /projects/storybook-ui/src/lib/ e deletamos tudo de lá. Nessa mesma pasta vamos criar o módulo e componente simple-button.

# dentro da pasta /projects/storybook/src/lib

ng g m simple-button # versão curta de ng generate module

ng g c simple-button --export # versão curta de ng generate componente

E vamos dar uma cara de botão para o nosso componente:

import { Component, Input } from '@angular/core';

@Component({
  selector: 'ui-simple-button',
  template: `
    <button>{{text}}</button>
  `,
  styles: [``]
})
export class SimpleButtonComponent {

  @Input() text = 'clique aqui';
}

Agora, vamos no arquivo /projects/storybook/src/public_api.ts e substituir todo o conteúdo desse arquivo por:

export * from './lib/simple-button/simple-button.component';
export * from './lib/simple-button/simple-button.module';

Para usar esse componente precisamos gerar o arquivo final da biblioteca:

ng b storybook-ui # versão curta de ng build

Reescrever o /src/app/app.component.html:

Ola Mundo!
<ui-simple-button></ui-simple-button>

E adicionar o SimpleButtonModule ao /src/app/app.module.ts:

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { SimpleButtonModule } from 'storybook-ui';

import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    SimpleButtonModule // modificado
  ],
  providers: [],
  bootstrap: [AppComponent]
})
export class AppModule { }

Por último, vamos servir nossa aplicação e ver como ela está no http://localhost:4200 :

ng s # versão curta de ng serve angular-storybook

Pode comparar o seu progresso com a tag v1.2 do repositório

Instalando o Storybook

O Storybook tem um guia de como fazer a instalação em um projeto Angular e o jeito mais fácil é só usando uma única linha:

npx -p @storybook/cli sb init --type angular

Executando essa linha no seu projeto, ele:

instala todas as dependências necessárias
adiciona os scripts storybook e build-storybook no seu package.json
cria os arquivos de configuração pro Storybook
cria as histórias de exemplo no seu projeto principal

Para ver o Storybook em ação, é só rodar o comando:

npm run storybook

Tudo bonito, tudo rodando. Mas, a configuração do Storybook está apenas pro seu projeto principal, e não para a sua biblioteca. Além disso, você sabe o que foi adicionado e para que? Então vamos voltar no tempo e seguir de forma manual.

Fazendo a instalação manualmente

1) Instale as dependências

npm install @storybook/angular babel-loader @babel/core --save-dev

2) Adicione os scripts de npm

{
  "scripts": {
    "storybook": "start-storybook -p 6006",
    "build-storybook": "build-storybook"
  }
}

O script storybook vai executar o start-storybook para exibir nossas histórias no http://localhost:6006. O build-storybook vai executar o build-storybook que vai gerar os arquivos estáticos do Storybook na pasta storybook-static.

Você pode definir o diretório final mudando o comando build-storybook por build-storybook -o /dist/storybook, colocando os arquivos estáticos no mesmo diretório que os builds gerados pelo seu projeto.

3) Crie o arquivo de configuração

É esse o arquivo que o Storybook vai usar para saber onde ele pode procurar as nossas histórias e como identificar os arquivos. No caso, vamos procurar arquivos com .stories.ts neles, dentro das pastas src e projects.

Crie o arquivo .storybook/config.js com o seguinte conteúdo:

import { configure } from '@storybook/angular';

configure([
  require.context('../src', true, /\.stories\.ts$/),
  require.context('../projects', true, /\.stories\.ts$/)
], module);

4) Configure o Storybook para funcionar com TypeScript

Como o @storybook/angular usa o ForkTsCheckerWebpackPlugin, precisamos criar o arquivo .storybook/tsconfig.json:

{
  "extends": "../tsconfig.json",
  "exclude": [
    "../src/test.ts",
    "../src/**/*.spec.ts",
    "../projects/**/*.spec.ts"
  ],
  "include": [
    "../src/**/*",
    "../projects/**/*"
  ]
}

5) Escreva sua história 🎉

Finalmente! Agora vamos criar nossa própria história e ver como ela se comporta.

Dentro da pasta do nosso componente simple-button, vamos criar o arquivo index.stories.ts com o conteúdo a seguir:

import { SimpleButtonComponent } from "./simple-button.component";

export default {
  title: 'UI | Button'
};

export const withDefaultValues = () => ({
  component: SimpleButtonComponent
});

export const withText = () => {

  return {
    component: SimpleButtonComponent,
    props: {
      text: 'Ola'
    }
  }
};

Essa é uma das formas que podemos escrever as histórias. Ela é chamada de CSF (Component Story Format). Também temos a StoriesOf API e o MDX Syntax, que está por vir. Como o CSF é um adição nova no Storybook, boa parte dos exemplos da internet vão estar usando o StoriesOf API.

Dessa forma estamos falando que temos o componente Button, dentro do agrupador UI, com as histórias "With Default Values" e "With Text".

UI
└── Button
    ├── With Default Values
    ├── With Text

6) Rode o projeto

Rode o projeto com o npm run storybook e veja o resultado final:

Pode comparar o seu progresso com a tag v1.3 do repositório

Próximos passos - addons

Agora que você aprendeu como configurar o Storybook e escrever uma história, você pode melhorar a qualidade das suas histórias com simples pluggins, chamados de addons.

Por exemplo, com o addon de actions você pode adicionar logs para ações, como clicks, e ouvir o que eles estão enviando. Com o addon de knobs você pode expor @Inputs do seu componente e altera-los na hora.

Pra não ficar só na explicação e sonhos, vamos montar ele agora. É muito fácil.

1) Instale as dependências

Além dos pacotes óbvios do knobs e do actions, precisamos também instalar o pacote do addons, que vai ser responsável por carregar os addons no Storybook.

npm install --save-dev @storybook/addons @storybook/addon-knobs @storybook/addon-actions

2) Crie o arquivo de configuração dos addons

Crie o arquivo .storybook/addons.js com a seguinte configuração:

import '@storybook/addon-knobs/register';
import '@storybook/addon-actions/register';

A ordem que você importa eles é importante. Ela vai dizer a ordem em que esses addons vão aparecer nos paineis

3) Aplique os addons na sua história

No nosso caso, vamos usar o knobs para expor o @Input text e o actions para exibir uma mensagem ao clicar no botão. Como vamos lidar com um evento e não uma propriedade, não podemos mais usar o component na história withText, pois o props só define propriedades e não eventos. Precisamos usar o template, mas para usarmos o template, precisamos definir o módulo com o componente SimpleButtonComponent.

No final das contas, o nosso index.stories.ts do SimpleButtonComponent vai ficar assim:

import { SimpleButtonComponent } from "./simple-button.component";
import { text, withKnobs } from '@storybook/addon-knobs';
import { moduleMetadata } from '@storybook/angular';
import { action } from '@storybook/addon-actions';

export default {
  title: 'UI | Button',
  decorators: [
    withKnobs,
    moduleMetadata({declarations: [SimpleButtonComponent]})
  ],
};

export const withDefaultValues = () => ({
  component: SimpleButtonComponent
});

export const withText = () => {
  return {
    template: `
        <ui-simple-button
          [text]="text"
          (click)="click($event)"
        ></ui-simple-button>
    `,
    props: {
      text: text('Text', 'Ola'),
      click: action('Clicou')
    }
  }
};

E quando rodarmos o Storybook:

Pode comparar o seu progresso com a tag v1.4 do repositório

Conclusão

Agora, você sabe como...
✅ Instalar e configurar o Storybook
✅ Criar histórias para componentes
✅ Instalar e configurar addons

Você não vai ter mais problemas em relação ao que sua aplicação tem ou não tem, e o desenvolvimento vai seguir com mais confiança e agilidade, por poder testar as mudanças em diversos cenários.

Se você se interessou pelo Storybook e quer saber o que mais ele pode fazer, você pode começar a ver como...
❗ Aprender o que compõe uma história
❗ Exportar e deployar arquivos estáticos das histórias
❗ Tematizar o Storybook
🎉 E muito mais

Se você ❤️ esse artigo, não deixe de me seguir e compartilhar com seus colegas. E se achar que tem algo para mudar no artigo, não deixe de comentar!

Te vejo na próxima! 😬

DEV Community: Klaus Kazlauskas

The saltiest and wrongest article about Big O ever

Nobody talks like that

Infinites can be bigger than others, but why care?

I'm tired

Resources

Make your life easier with Set Compositions

Difference

Intersection

Symmetric Difference

Union

Is Disjoint From?

Is Superset/Subset Of?

TIL: Gemini can analyze errors directly on the browser

Keep In Mind

Conclusion

Hora de substituir o Redux

O que é tudo?

Mas qual é o problema do Redux?

Quantidade de código

Gerenciamento de cache

Conclusão

Simplificando Feature Flags com DevCycle

Mas... por que o DevCycle? 😐

Preço! 💰

Vamos começar 🏁

1) Crie um projeto React e instale o DevCycle:

2) Crie um arquivo .env

3) Adicione uma feature flag ao projeto

4) Configurando o DevCycle e sua feature flag

Recapitulando 🔛

Finalizando 🎉

Data Driven Design System com Omlet

O que é o Omlet?

Primeiros passos com o Omlet

Aba de análise (Analytics)

Aba de componentes

Página de tags

Casos de uso

Concluindo

Iniciando um Design System com Storybook 5.3 e Angular

Como criar uma biblioteca de componentes com Angular e Storybook

Klaus Kazlauskas ・ Jan 3 '20

Preparação

klauskpm / angular-storybook

Repositório para ensinar a usar Storybook com Angular.

Atualizando os pacotes

Configuração declarativa

main.js

Antes

Depois

preview.js

manager.js

Separadores de hierarquia

Fazendo a atualização em massa

Perdemos o root!

Migração

Saber mais sobre

Declarative Storybook configuration | by Norbert de Langen | Storybook | Medium

Norbert de Langen ・ Jan 27, 2020 ・ Medium

Geração automática de documentação

Configurando o DocsPage

Instale as dependências

Adicione os scripts de geração

Explicando o compodoc

Configure o @storybook/addon-docs

Adicione uns enfeites (opcional)

Resultado

Saber mais sobre

Storybook Docs for new frameworks | by Michael Shilman | Storybook | Medium

Michael Shilman ・ Jan 14, 2020 ・ Medium

Iniciando um Design System com MDX

Como escrevemos em MDX

Configurando o MDX

Instale as dependências

Altere o main.js

Criando um arquivo MDX

Veja o resultado

Criando histórias com MDX

Blocos do @storybook/addon-docs

`main.js`

`preview.js`

`manager.js`

Norbert de Langen ・ Jan 27, 2020 ・
Medium

Explicando o `compodoc`

Configure o `@storybook/addon-docs`

Michael Shilman ・ Jan 14, 2020 ・
Medium

Altere o `main.js`

Criando um arquivo `MDX`

Blocos do `@storybook/addon-docs`

Michael Shilman ・ Jan 14, 2020 ・
Medium

Dominic Nguyen ・ Sep 24, 2020 ・
Medium

3) Crie o arquivo `commitlint.config.js`

4) Altere o seu `package.json`

5) Crie o arquivo `.versionrc`

3) Configure o `husky` no package.json

1) Instale e configure o `commitizen`

`standard-version`

1) Instale o `standard-version`

2) Altere seu `package.json`

1) Crie o arquivo `.versionrc`

2) Altere o `package.json` (Opcional: GitLab)

3) Crie o arquivo `commitlint.config.js`

4) Altere o seu `package.json`

5) Crie o arquivo `.versionrc`