Tenho uma pergunta sobre rolagem: no Android existe algo chamado recyclerview Crie listas dinâmicas com RecyclerView | Android Developers Ele reutiliza componentes em vez de adicionar cada vez mais durante uma rolagem. Parece que o Discourse não faz isso? Por que é assim? Existe uma estratégia diferente usada? Tenho a vaga ideia de que o sistema de widgets vdom personalizado foi criado para resolver esse problema (de uma lista crescente de elementos DOM), mas, para ser honesto, ainda não entendo como isso resolve o problema. 
Talvez alguém possa esclarecer isso 
3 curtidas
Carregamos apenas 20 posts por vez, usando o que é chamado de “virtual scrolling”.
4 curtidas
o que acontece com os elementos DOM antigos? Se eu continuar rolando, imagino que mais e mais elementos sejam adicionados à árvore DOM. Eles são removidos em algum momento?
1 curtida
Não, nós os deixamos por perto, temos uma peça de lógica de “invisibilidade” que substitui elementos por um espaço reservado quando você está muito longe da viewport, então, quando você se aproxima do elemento, nós o revelamos renderizando-o novamente. O limite para essa mágica é bem alto.
4 curtidas
@sam Existe algum artigo que você possa me indicar que compare essa técnica com a reciclagem de componentes? Eu estaria interessado em ler mais sobre isso. Como você tomou essa decisão? Imagino que A tour of how the Widget (Virtual DOM) code in Discourse works também esteja relacionado a isso.
1 curtida
Não acho que tenhamos um artigo, mas posso estar enganado. Talvez @eviltrout se lembre se documentamos algumas de nossas decisões sobre o pós-cloaking. Não tenho certeza.
2 curtidas
Faz muito tempo, então infelizmente não me lembro.
Não acho que chegamos a analisar completamente os componentes de reciclagem. O camuflamento foi uma grande vitória e resolveu nossos problemas na época.
4 curtidas
@eviltrout Vi esta postagem Evil Trout Inc.
Depois de anos esperando por um avanço no desempenho do Android ou do Ember, decidimos que era hora de tomar a opção nuclear: substituímos o mecanismo de renderização do Ember para nossa visualização mais comum por um renderizador personalizado baseado em DOM virtual.
Então, parece que o sistema vdom/widget no discourse foi construído como uma resposta aos problemas de desempenho do Android.
Este commit que introduz o cloaking parece acontecer depois do sistema vdom/widget:
O cloaking e o sistema vdom/widget estão de alguma forma relacionados? Parece que ambos abordam o desempenho. A reciclagem de componentes reduziria significativamente a quantidade de elementos DOM, então algo como o sistema vdom/widget não seria necessário, certo?
2 curtidas
Tivemos o cloaking antes do vdom, mas ele foi reimplementado depois que percebemos que também o precisávamos lá.
A reciclagem de componentes deve reduzir a memória e melhorar as coisas em tópicos grandes, mas não acelerará o tempo de renderização, o que os widgets fazem consideravelmente.
3 curtidas
Não se pode subestimar que todas as questões de desempenho envolvem compensações. Acho que o Ember faz a coisa certa aqui e se concentra em aplicativos que são organizados e escalam à medida que você adiciona mais recursos. Para a grande maioria das visualizações em seu aplicativo, a sobrecarga do framework não o preocupará. No entanto, se você estiver renderizando muitos componentes aninhados com muitas vinculações, a situação pode se tornar patológica.
Embora o Discourse possa parecer simples na superfície, cada postagem é renderizada com vários componentes. Temos muitos botões dinâmicos, links e efeitos aplicados toda vez que uma postagem é renderizada com mais de 150 atributos envolvidos.
Eu vi isso no post do blog que @eviltrout escreveu. Parece que o desempenho do Ember não é um problema em geral, mas apenas no caso específico dos tópicos do Discourse, certo? Os tópicos do Discourse são uma lista muito longa de componentes (posts) que têm muitos componentes dentro deles (botão de resposta, botão de curtir, etc.). É isso que leva à degradação do desempenho da renderização.
vdom/widgets aliviam esse problema em certa medida, porque tornam o processo de renderização menos custoso. Mas, em algum momento, a quantidade de elementos DOM se torna tão grande que eles precisam ser reduzidos, ocultando-os.
Reciclar componentes significa evitar esse problema completamente, tendo apenas um número fixo de elementos DOM na tela, que são reaproveitados à medida que o usuário rola o conteúdo.
Por favor, corrija-me se eu caracterizei algo incorretamente.
Obrigado,
Spirobel 
2 curtidas