Discussão sobre novas melhorias e possiblidade de v4.0.0

[RafaelGondi]

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.

Essa discussão ficará aberta por tempo indefinido, por enquanto.
As sugestões acatadas serão posteriormente convertidas em issues.

A ideia da v4 é a implementação de melhorias mais incrementais do que a migração da v2 para a v3.

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

[johnn1sbo3s]

• Implementar o pesquisar com Enter nos inputs de texto;
• Criar o componente LoadingIndicator
• Criar um tutorial ensinando como adicionar um novo ícone ao Cuida Icons
• Automatizar a atualização da versão do projeto no package.json

[RafaelGondi]

Em que cenários a gente usaria o LoadingIndicator e em quais outros a gente usaria skeletons?

[johnn1sbo3s]

Geralmente, vejo skeletons sendo usados quando há interação dentro da própria tela. Por exemplo: em um lazy loading ou a ativação de um switch que gera uma nova requisição e as informações vão mudar. Outro uso para o skeleton é para conteúdo secundário da tela (quando o principal já foi carregado).
Já o LoadingIndicator é usado na troca de telas, como na seleção de um novo módulo pela navegação lateral.

NProgress: https://ricostacruz.com/nprogress/

Cabe um estudo maior sobre a utilização dos dois.

[IhGori]

Adicionar novos itens ao pipeline buscando otimizar e tornar mais eficientes testes de usabilidade e de qualidade:

• Para testes automatizados, uma opção seria o Cypress, a partir desta ferramenta permite gerar também relatórios em vídeos de todos testes como também screenshots para momentos que falharem;
  

• Utilizar o Google LightHouse o qual permite avaliar a aplicação em pontos como Desempenho, Acessibilidade e Práticas recomendadas que são classificadas em escala de 0 a 100, o que poderíamos inferir uma nota mínima de qualidade para que possa permitir o merge.
  

[RafaelGondi]

Penso que o Cypress pode ser útil mais para componentes com uma certa complexidade, que utilizam vários "sub componentes" internamente, já que pra componentes mais simples o ganho de testes E2E é baixo por eles serem isolados. Pra maioria dos casos acho que deveríamos aumentar a cobertura de testes com Vitest, o que tu acha?

Outro ponto que penso é sobre o pipeline. Criaríamos regras para o cypress passar só em certos componentes e em outros não? Como ficaria?

[IhGori]

1. Para primeiro ponto citado, também acredito que aplicar testes automatizados em componentes com maior complexidade se torna mais efetivo, contudo, podemos criar uma espécie de relatório registrado que tudo está funcionando como esperado como também do que não está.

Dado isso, surge a questão sobre o esforço repetitivo sobre componentes simples (Já que atualmente o Cuida apresenta uma grande quantidade de componentes) para criar os testes mínimos de renderização, mas a própria ferramente fornece seguinte funcionalidade:

Como pode ser observado na imagem, ela mesmo reconhece todos componentes criados na aplicação e consegue já gerar esse arquivo dentro do projeto, o que de fato teríamos que nos preocupar em elaborar de forma mais adequada, todas funcionalidades dos componentes que apresentam maior complexidade ou que sua usabilidade necessite de outros componentes.

Em relação a complexidade de codificação dos testes relacionados ao Cypress em si pelo que andei estudando e conversando com @lucasn4s, a estruturação de testes se torna extremamente semelhante ao padrão utilizado Vue Test Utils ou ao próprio Vitest que já é comumente utilizados em testes do front (Já que a base utiliza-se do javascript e a formatação segue a mesma estrutura), problema maior, acredito que está relacionado em tentar introduzir essa cultura de testes no front.

2. Em relação ao segundo ponto, acredito que sim, é possível gerenciarmos ao pipeline de quando deve ser executado e como ser executado, como também ações a serem tomadas de acordo com o que aconteça, por exemplo criar relatório dos testes a partir de vídeo da execução dos componentes, como também screenshots de testes que falharem.

Observando que desde que a idéia principal seja testar abordar os fluxos positivos (de sucesso) o cypress se tornaria um dos ideais, justamente pela possibilidade de gerenciar e registrar o que está acontencendo, mantendo a base de codificação dos testes bastante semelhante as outras opções, mas caso seja necessário gerenciar fluxos de erro para abordagem 100% dos casos de teste (o que provavelmente seria o ideal), a aplicação das outras opções se torna essenciais.

Outro ponto a se observar e aprofundar conhecimentos quanto de sobrecarga o Cypress pode aplicar quando se está trabalhando com uma grande carga de testes (Ainda não fiz essa avaliação), o que para esse caso também a depender das respostas, se tornaria ideal criar uma epécie de "Testing Style Guide", para decisão de qual tipo de teste ser aplicado (Cypress, Vitest ou qualquer outro que seja visado no futuro) como também de fato o que deve ser testado.

[johnn1sbo3s]

Adicionar o .fire ao componente DialogModal.

[lucasn4s]

Fazer uma versão do Multiselect do zero.

[tassiocaique]

Ter a possibilidade de versões "compact" (com padding reduzido) dos inputs.

[lucasn4s]

O planejamento da v4 passou para a #1140, que organiza o escopo da próxima major e traz as sugestões feitas aqui. Esta discussão fica encerrada, mas continua disponível para consulta.