Sim! O uso do JQuery em conjunto com o Ember pode trazer diversas armadilhas que vão resultar em lentidão, uso excessivo e vazamento de memória (memory leak), transições lentas, scroll lento podendo causar a impressão de que Ember é lento!
É importante ressaltar que eliminar o uso do JQuery não vai resolver 100% o problema de performance, o que resolve de fato é ter código bem escrito.
Vamos lá!
Erro 1: Não destruir os “event listeners”
Não destruir os event listeners não é um problema exclusivo do JQuery, este é um problema que precisa ser tratado manualmente para cada listener registrado. *Se você registra um event listener, você precisa destruí-lo em algum momento, é uma regra básica! *Pensar nos detalhes fazem toda a diferença no uso de memória e performance da sua SPA.
No Ember, sempre que você registrar qualquer evento em didInsertElement, você deve destruí-lo corretamente sempre que o componente for destruído usando willDestroyElement.
No exemplo acima, parece que o registro do listener será destruído corretamente. Porém temos um bind que fará duas referências diferentes, logo não será destruído, pois não é o mesmo listener.
Confira o funcionamento correto do bind:
Exemplo de execução do bind
A forma correta para destruir todos os listeners de uma vez é usar $(this.element).off(‘click’). A outra é usar a referência direta do listener a ser destruído. Assim utilizamos exatamente a mesma referência de memória:
Neste exemplo, clickHandlerRef recebe uma referência do metódo que será vinculado, guardando-a para posteriormente ser destruído em willDestroyElement.
Essa abordagem é boa, porém pode aumentar a complexidade do código dificultando a leitura e compreensão.
Isso é válido inclusive para todo e qualquer listener personalizado que você registrar.
Quando um listener não é destruído, o elemento (nó) mantém uma referência para todos os elementos internos. Na melhor das hipóteses, este será apenas um vazamento de memória (memory leak), porém pode gerar outros problemas.
Próximo exemplo:
No código acima, o desenvolvedor pressupõem que todos os itens que correspondem a li.link deveriam ter um listener para o evento de click. Porém, se esse componente for utilizado duas ou mais vezes na mesma tela, esse listener para li.link será duplicado. Durante a destruíção de um componente, neste caso, ele vai destruir todos os listeners, incluindo os listeners do outro componente, pois não foi definido um escopo de seleção.
Para resolver isso alguns desenvolvedores adicionaram identificação nos listeners para contornar o problema de escopo.
jQuery('li.linked').on(`click.${this.id}` ...
...
jQuery('li.linked').off(`click.${this.id}`);
Isso somente resolve o problema de destruição dos listeners, porém não resolve os listeners duplicados.
A maneira correta de resolver isso é utilizar escopo do componente com this.$() ou $(this.element) e usar o find. Além de resolver o problema de listeners, evita que elementos fora do escopo do componente sejam afetados.
jQuery(this.element).find('li.link').on('click', ...
...
this.$().find('li.link').on('click', ...
Erro 2: Uso de seletores globais
Existem diversos erros no uso de seletores, e aos poucos, temos erros compostos de mais erros são criados. Vimos nos exemplos acima que nosso componente involuntariamente acrescentou listeners duplicados em itens dentro de outro componente.
Na prática a solução é definitivamente usar selector JQuery delimitado dentro do escopo do componente. Quando você ignora este conselho, você consegue produzir bugs divertidos.
Engraçado? Vou explicar a seguir!
Antes disso da uma olhada na documentação de element.getElementsByTagName e document.getElementsByTagName.
O retorno deles é um HTMLCollections, isso significa que é sempre atualizado quando ocorrer uma mudança no DOM:
An HTMLCollection in the HTML DOM is live; it is automatically updated when the underlying document is changed.
O metódo getElementsByClassName tem o mesmo comportamento.
Já querySelectorAll retorna NodeList, ou seja, NodeList é um retorno estático que não é modificado quando o DOM é atualizado.
Veja dois exemplos de código (habilite o console do seu navegador para ver o log)
https://codepen.io/aureliosaraiva/pen/ObWbeM
https://codepen.io/aureliosaraiva/pen/VmPmJJ
Certo, o que isso tudo significa?
JQuery usa a lib Sizzle para encontrar elementos no DOM. Sempre que puder, ela vai utilizar esses seletores para se conectar aos elementos. Isso tudo significa que quanto mais alto na hierarquia o HTMLCollection estiver conectado, mais mudanças ele terá que observar e mais trabalho de processamento ele irá realizar.
Quando você usa um seletor global para fazer alguma coisa, sempre que HTMLCollection precisar atualizar, uma serie de processamentos são realizados e diversas chamadas JQuery serão executadas.
Existem dois momentos críticos de performance em uma SPA: (1) quando ocorre uma transição da rota A para a rota B, e (2) quando é realizada uma reciclagem para reduzir a quantidade de elementos DOM na tela. Um único seletor JQuery utilizando uma lista HTMLCollection é capaz de causar lentidão tornando sua SPA instável.
Erro 3: Caching de seletor JQuery
Existem diversos tutoriais de melhoria de desempenho que sugerem o armazenamento em cache dos seletores JQuery. A sugestão não é errada, o problema é não ter um controle para remover esse cache depois de utilizá-lo. Seletores em cache muitas vezes fazem referência a elementos no DOM resultando em memory leak, felizmente isso muitas vezes é temporário (até que o componente seja destruído), mas dependendo de como e onde você fez o cache, o problema de memory leak pode ser permanente.
Erro 4: Uso de plugins JQuery
Imagine o seguinte, você está com um prazo curto, e você precisa criar um recurso drag&drop, ou utilizar um carrossel ou até mesmo uma visualização especial de imagem, etc. Você lembra que quando trabalhava só com JQuery, você utilizava um JQuery Plugin para resolver o problema e sempre funcionava. Com apenas uma chamada ele fazia tudo por você. Talvez alguém até já tenha criado um addon no Ember para ser instalado.
Poucos dias depois de começa a utilizar surgem as primeiras falhas: minha SPA não está respondendo. O número de erros aumenta, lentidão, memory leak e tudo fica fora de controle.
Você já usou este plugin mil vezes, o que aconteceu?
Eis o que aconteceu.
O mundo não é mais o mesmo!
Por mais de uma década, desenvolvedores de JavaScript foram capazes utilizar diversos plugins JQuery para resolver problemas em curto espaço de tempo. A maioria dos plugins JQuery não foi construído pensando em uma SPA.
No passado, os desenvolvedores não precisavam pensar na destruição do DOM e dos event listeners. Um plugin/biblioteca era instanciado no carregamento da página e existia até o momento que ocorria uma atualização completa ou um nova página era chamada.
Este código não está preparado para páginas web dinâmicas, e tão pouco essa situação vem sendo corrigida pelos mantenedores. Porque se importar então? O padrão plugin é um conceito morto, componentes e frameworks baseados em componentes tem contribuído para isso nos últimos anos.
A probabilidade do seu plugin JQuery favorito não ter um processo de limpeza do DOM é alta. Como mencionado acima, seletores com HTMLCollection são perigosos. Quais desses o plugin utilizam? Como é o cache de seletor?
Os vazamentos de memória e problemas de performance estão em toda parte, o uso de dois ou três plugins combinados podem trazer diversos problemas.
É importante sempre verificar se o plugin/biblioteca implementam destroy, teardown ou cleanup (ou algo semelhante) e verificar se elas são executadas corretamente quando se está destruíndo o componente. Mesmo os plugins/biblioteca que implementam esse recurso, nem sempre fazem um trabalho bem feito. Portanto, o seu único recurso é implementar e, em seguida, se certificar (com uso de profiling) de que nenhum memory leak ficou pendente.
Conclusão
Problemas com event listeners e seletores não são os únicos causadores de instabilidade. Desenvolvedores estão viciados em suas rotinas de trabalho e esquecem de dar atenção aos detalhes, ou até mesmo de buscar mais informações de como as APIs funcionam.
Como resolver esses problema?
Você pode monitorar, estudar o código do plugin/biblioteca, se houver essas falhas, você pode sugerir um Pull Request e contribuir com a comunidade. No final todos ganham!
Comunidade EmberJS no Brasil
- Esse texto é parte de uma iniciativa da comunidade EmberJS Brasil, que busca disseminar conteúdo sobre
- Ember, que seja de qualidade, autoral ou traduzido. Siga nosso Twitter!
- Participe da comunidade global de Ember no Slack!
- E acesse o canal: #lang-portuguese!