Closed patrickalima98 closed 6 years ago
mateusmirandaalmeida
commented
6 years ago Bacana Patrick, obrigado pelo feedback e atenção sua. Vamos nos certificar de analisar cuidadosamente cada item reportado. Me comprometo em te dar uma posição o mais rápido possível.
patrickalima98
commented
6 years ago OK, muito obrigado @mateusmirandaalmeida
mateusmirandaalmeida
commented
6 years ago Eai @patrickalima98 beleza? Analisamos os pontos que você relatou, então vamos por partes...
Primeiro você comentou que seria legal se tivéssemos um pacote de componentes, caso eu tenha entendido corretamente. Então temos um repositório https://github.com/ui-capivara que tem alguns componentes que fazemos em capivarajs tanto para validar o framework quanto para próprio uso nosso.
Logo em seguida você comentou que poderíamos deixar customizar o prefixo dos componentes, acreditamos que esse não seja o momento, nosso objetivo é padronizar a nomenclatura de componentes feitos em capivara, assim como hoje é feito em angular na quais seus componentes são padronizados em ng.
Sobre os pontos para revisar:
Você detectou que no windows nosso CLI não estava funcionando 100%, conseguimos simular esse problema e nossa equipe já está trabalhando nisso.
Um pouco mais abaixo você informou que os arquivos estavam ficando grandes demais, o que acontece é que se você usar o padrão ES6 para importar nossas dependências isso reduziria bastante o tamanho, quando é feito o npm run prod o capivarajs vai junto no arquivo minificado o que deixa ele grande, o mais correto seria você não importar o arquivo minificado no seu projeto e sim o componente normal. Para que você consiga entender melhor, vamos imaginar que você tenha 100 componentes criados em capivarajs e você importa os minificados desses 100 componentes na sua aplicação, isso iria resultar em 100x o codigo capivara no seu projeto. Caso não importamos os minificados e sim o componente o próprio webpack cuidaria para que as importações não sejam duplicadas.
Por fim você relatou encontrar o package.json no arquivo minificado, isso acontecia porque o capivarajs importava o package para exportar sua versão atual na window: capivara.version, então para resolver removemos a importação package e atualizaremos essa informação sempre que lançarmos uma nova versão. Então isso já está resolvido.
Sobre separar os arquivos isso não é algo possível, o capivarajs não faz o transpiler do seu componente para essas tecnologias e sim faz com que eles funcionem em conjunto. Hoje o código que faz com que seu componente funcione junto a essas tecnologias é muito pequeno, pode ser visto em https://goo.gl/qQdkqH. Então podemos garantir que não é a integração com eles que estava deixando o arquivo grande.
Considerações Com suas sugestões tivemos várias ideias para melhorar nosso framework, tanto em performance quanto em boas praticas, por isso lançamos a versão 3.10.0 com bastante coisa nova.
1 - Remoção do package.json 2 - Melhoria no tamanho do capivarajs 3 - Revisão das dependências 4 - Melhoria em 40% de performance 5 - Criação de decorators que deixa mais elegante a criação de componentes. Exemplo em: https://goo.gl/GbF9hK
patrickalima98
commented
6 years ago @mateusmirandaalmeida primeiramente gostaria de parabenizar vocês pela ajuda e atenção, e pelo excelente trabalho que fizeram com o capivara nesta nova versão, já comecei a usar, fiz alguns testes e ficou realmente muito bom!
Agora sobre as bibliotecas era o seguinte, existe alguma forma de fazer uma biblioteca de componentes com o capivara? Por exemplo vou criar uma biblioteca chamda X, e nela ter a possibilidade de ter inumeros componentes já incluidos para usar com o Webpack e na Web também? Assim quem for usar terá incluir somente a biblioteca x e nelá terá vários componentes para usar.
Agradeço desde já.
Olá equipe do CapivaraJS, eu estou muito interessado em utilizar o framework de vocês para nossos projetos, acredito que outras pessoas também verão o grande potencial do Capivara, porém eu passei por algumas situações e estive investigando algumas coisas e tomei a liberdade de criar uma lista com pontos para verificar e comparar.
Lista novas funcionalidades:
Pontos para revisar
Erro ao renomear arquivos No Windows parece não gerar o projeto 100%, os componentes da pasta, src/component/ não foram renomeados quando criei o projeto, ficando como project-name.component, em outras vezes que tentei com outros exemplos as vezes funciona, as vezes não.
Tamanho dos arquivos O Tamanho dos arquivos gerados está muito grande, gerando um simples botão com duas funções de click, que exibem um alert, tornaram o arquivo .min com 138 KB, a versão não minificada está com 740KB... Existe alguma maneira de diminuir o tamanho dos arquivos gerados? se alguém for usar 3 componentes irá passar dos 200KBs de arquivos .js, é muito maior do que qualquer outra lib, como Vue. Além disso notei que tem muita configuração do Webpack nos arquivos gerados, bem como comentários e arquivos de licença, esses projetos ou dependências que vocês usam são compiladas junto com a lib ? caso não poderia remover.
Ainda sobre tamanho, encontrei parte dos arquivos package.json no meio dos arquivos js gerados, pelo CLI. Isso é usado para alguma coisa ? Vejam abaixo as imagens abaixo.
Meu arquivo JS não minificado, inclui partes do meu package.json
Isso está presente nos arquivos de exemplos de vocês também, retirado de: https://unpkg.com/@uicapivara/cp-counter@1.1.1/dist/cp-counter.min.js
Uma outra coisa, vocês conseguiriam separar os arquivos gerados? Por exemplo não sei o por que do tamanho grande dos arquivos, talvez criar um único arquivo que trabalha com Vue, React, Angular e JS seja o motivo para ficar tão grande, não teria como o CLI separar os arquivos, criando os arquivos:
Desta forma livraria um pouco o peso dos scripts e cada um que distribua seus componentes irá distribuir os arquivos para cada framework, assim um cara que trabalha com Angular não teria um componente que tem algo internamente que o faça funcionar no Vue. De maneira resumida isso tornaria os scripts mais levez, menores e seria mais viável alguém usar os componentes, pois assim eles não vão pesar na transferência, continuam fazendo o seu papel, porém muito mais enxutos e específicos para cada Framework.
Adoraria ver as respostas e considerações de vocês, se precisar de alguém para ajudar, também estou disposto.
Agradeço desde já.