Melhorias no Cuida para a próxima versão (v3.0.0)

[RafaelGondi]

Discussão sobre as melhorias para a v3.0.0

Galera, vamos listar nessa discussão sugestões de melhoria para serem lançadas na próxima versão do Cuida. Problemas e melhorias cuja correção/implementação envolvam breaking changes e causem incompatibilidades nas APIs dos componentes são importantes de discutirmos aqui.

Também é importante debatermos a migração do DS para as novas tecnologias que a gente vêm discutindo recentemente (Vue3, Vite e TypeScript), visto que elas vão causar breaking changes.

Por último, pontos de melhoria no Design Kit (Cuida no Figma) também são interessantes de serem trazidos aqui.

Essa discussão ficará aberta por 1 mês (até 01/09), momento a partir do qual passaremos a debater questões relativas à implementação.
As sugestões acatadas serão posteriormente convertidas em issues.

Caso vocês tenham novas sugestões, objeções, observações, etc. é só colocar abaixo. o/

[RafaelGondi]

Remover o bootsrap-vue como dependência de projeto

[RafaelGondi]

• Adiciona no readme aviso para que novos componentes não utilizem bootstrap-vue
• Adiciona nos templates de PR, e issue aviso para que novos componentes não utilizem bootstrap-vue

[RafaelGondi]

• Substituir o b-table pela tabela do Cuida na documentação
• Remover b-buttons e b-nav

[RafaelGondi]

Remover Feather Icons e material-icons como dependências de projeto

[RafaelGondi]

Remover o componente Dropdown, visto que já temos o ClusteredMultiselect como componente com o mesmo propósito e ele está atualizado com os tokens do Cuida.

[tassiocaique]

Sou à favor, mas acredito que esse ClusteredMultiselect deveria ser renomeado.

[RafaelGondi]

Migrar os testes de Jest para Vitest A documentação do Vue está recomendando o uso do Vitest em projetos Vite:

E como a nova versão usa Vite e o Vitest é compatível com o Jest, acho que valeria o teste

[RafaelGondi]

-V3

[RafaelGondi]

Implementado em: #286

[johnn1sbo3s]

Ajustar variantes de componentes que não estão funcionando corretamente no Figma. Exemplo: botões

[RafaelGondi]

• Botões: resolvido
• Mapear componentes com conflito de props / variantes

[johnn1sbo3s]

Discutir sobre a tipografia utilizada no Figma.

[RafaelGondi]

• Analisar novas possibilidades de fonte
• Substituir a fonte no CS
• Refatorar tokens de tipografia

[tassiocaique]

Discutir a padronização das apis dos componentes. Se vai usar is-[NOME] para props booleanas, etc.

Obs.: Não sou a favor do "is-", foi só um exemplo.

[RafaelGondi]

Massa! Acho que a gente pode adicionar essas guidelines no CONTRIBUTING.MD e no Desing Kit.

[RafaelGondi]

• V3

[johnn1sbo3s]

Discutir sobre a mudança de DOs DON'Ts na documentação.

[RafaelGondi]

Esse modelo é legal, mas o "Quando usar / não usar" tem o mesmo problema do modelo que usamos hoje. Ele limita a escrita do que ver a seguir, como descrito no exemplo acima, a resposta tem que vir com "Quando precisamos....", "Quando o feedback...", "Quando necessitamos...", "Quando queremos...", etc

[GeissyMay]

Não acho que limite no mesmo nível. Pensei nessa forma pq deixa claro tanto quando usar quanto algumas informações a mais de boas práticas. Eu acho mais importante não mudarmos tanto a estrutura hoje e pensarmos mais em reformular o conteúdo/escrita. E não gosto muito do termo em inglês em uma documentação em português, pode ter em alguns design systems e ser reconhecido esse método mas não concordo.

[RafaelGondi]

Tu pode dar alguns exemplos de como a limitação ocorreria em nível diferente?

Com relação a mudar a estrutura, acredito que, caso achemos necessário, o momento de mudança é agora que estamos indo pra uma breaking change, indo pra versão 3.0 do projeto.

Sobre termos em inglês na documentação em português, além desse caso ser comum na indústria, também é bem comum utilização de termos e jargões em inglês por causa da nossa área (computação e design). Além disso, todos os nossos componentes, convenções de código e tokens, são em inglês. A tendência é que o projeto como um todo passe a ser em inglês no futuro.

[GeissyMay]

A estrutura do tópico/frase anterior "Recomendamos o uso {...} quando" pede, necessariamente, no início de cada tópico subsequente, a presença de algumas palavras específicas como "For", "Se", "Houver", "Estiver". Essa "obrigatoriedade" por sua vez condiciona o restante da frase a um formato um pouco mais engessado.

A utilização do "Quando usar" não coloca a necessidade de se iniciar o tópico subsequente dentro dos exemplos anteriores, o que, de certa forma, amplia o leque de possibilidades para frases mais simples, curtas e/ou claras.

Exemplo:

Quando usar

• Visualizar status associados com a lógica de negócios ou ações do usuário
• Precisar categorizar algo
• Mostrar conteúdos de Readonly

Quando não usar

• O badge puder ser removido pelo usuário
• Precisar clicar no componente para executar uma ação ou funcionalidade

[RafaelGondi]

Não entendi bem. Tomando o exemplo acima:
"Quando usar

Visualizar status associados com a lógica de negócios ou ações do usuário"

A gente tem dois verbos juntos (usar e visualizar) e a frase fica "Quando usar visualizar status...", de modo que me parece que esse formato exige a mesma estrutura, ou estrutura semelhante ao atualmente utilizado

[johnn1sbo3s]

Atualizar estilo do componente Badge no Figma.

[RafaelGondi]

PR aberto: #288

[johnn1sbo3s]

Criar tokens de container

[johnn1sbo3s]

Tokens de container para centralizar o conteúdo das páginas.
Hoje, o conteúdo é alinhado às margens, o que quebra a responsividade em telas maiores.

Exemplo:

A ideia é que tenhamos o conteúdo centralizado em telas com maior resolução, como faz, por exemplo,a página do Bootstrap:

Zoom em 100%:

Zoom em 67%:

[johnn1sbo3s]

Exemplo de tokens do Bootstrap:

[johnn1sbo3s]

Atualizar o componente Table no Figma para o padrão.

[johnn1sbo3s]

Criar componente de abas no Figma.

[RafaelGondi]

• Feito