無限スクロール - DiscourseはDOM要素を再利用していますか?

スクロールに関する質問があります。AndroidにはRecyclerViewというものがあります。RecyclerViewで動的なリストを作成する | Android Developers これは、どんどんコンポーネントを追加するのではなく、コンポーネントを再利用します。Discourseはこれを行っていないように見えますが、なぜでしょうか?異なる戦略が使用されているのでしょうか?カスタムVDOMウィジェットシステムがこの問題(DOM要素のリストが無限に増え続ける)に対処するために作成されたという漠然とした考えがありますが、正直なところ、それがどのように問題を解決するのかまだ理解できていません。:sweat_smile: 誰か説明していただけると幸いです。:smiley:

「いいね!」 3

一度に読み込まれるのは20件の投稿のみで、「仮想スクロール」と呼ばれるものを使用しています。

「いいね!」 4

古いDOM要素はどうなりますか? スクロールし続けると、DOMツリーに要素がどんどん追加されていくと思いますが、それらはいつか削除されるのでしょうか?

「いいね!」 1

いいえ、そのままにしておきます。「クローキング」というロジックがあり、ビューポートから非常に離れると要素をプレースホルダーに置き換えます。その後、要素に近づくと再レンダリングによってクローキングを解除します。この魔法のしきい値はかなり高いです。

「いいね!」 4

@sam このテクニックとコンポーネントのリサイクルを比較した記事をリンクしていただけますか?それについてもっと読んでみたいです。どのようにこの決定を下しましたか? A tour of how the Widget (Virtual DOM) code in Discourse works もこれに関連していると思います。

「いいね!」 1

記事はないと思いますが、間違っているかもしれません。@eviltrout は、ポストクローキングに関する決定の一部を文書化したかどうか覚えているかもしれません。わかりません。

「いいね!」 2

残念ながら、かなり前のことなので覚えていません。

リサイクルコンポーネントを完全に分析したことはなかったと思います。クローキングは大きな成果であり、当時の問題を解決しました。

「いいね!」 4

@eviltrout この投稿を見ました Evil Trout Inc.

Android または Ember のパフォーマンスのブレークスルーを何年も待った後、私たちは「最終手段」を取ることにしました。最も一般的なビューの Ember レンダリング エンジンを、カスタム仮想 DOM ベースのレンダラーに置き換えました。

したがって、Discourse の vdom/widget システムは、Android のパフォーマンスの問題に対応して構築されたようです。
このクローキングを導入するコミットは、vdom/widget システムの後に行われたようです。

クローキングと vdom/widget システムは、何らかの形で関連していますか? どちらもパフォーマンスに対処しているように思えます。コンポーネントをリサイクルすると、DOM 要素の数が大幅に削減されるため、vdom/widget システムのようなものは不要になるのではないでしょうか?

「いいね!」 2

vdomより前にクロージャを使用していましたが、そこでも必要であることに気づいたため、再実装しました。

コンポーネントのリサイクルは、メモリを削減し、大規模なトピックを改善するはずですが、ウィジェットが大幅に実行するレンダリング時間を短縮することはありません。

「いいね!」 3

パフォーマンスの問題はすべてトレードオフに関するものであるということは、いくら強調してもしすぎることはありません。Emberはこの点で正しいことをしており、整理されていて機能を追加するにつれてスケールアップするアプリケーションに焦点を当てていると思います。アプリケーションのほとんどのビューでは、フレームワークのオーバーヘッドは問題にならないでしょう。しかし、多くのバインディングを持つ多くのネストされたコンポーネントをレンダリングしている場合、状況は病理的になる可能性があります。

Discourseは表面上はシンプルに見えるかもしれませんが、各投稿はかなりの数のコンポーネントでレンダリングされています。投稿がレンダリングされるたびに、150を超える属性が関与する多くの動的なボタン、リンク、エフェクトが適用されています。」

これは@eviltroutが書いたブログ記事で見ました。Emberのパフォーマンスは一般的には問題ないようですが、Discourseのトピックという特定のケースだけですよね? Discourseのトピックは、多くのコンポーネント(投稿)が内部に多くのコンポーネント(返信ボタン、いいねボタンなど)を持っている非常に長いリストです。これがレンダリングパフォーマンスの低下につながります。
vdom/widgetsは、レンダリングプロセスをより安価にするため、この問題をある程度軽減します。しかし、ある時点でDOM要素の量が非常に大きくなり、それらをクローキングすることで削減する必要があります。
コンポーネントのリサイクルは、ユーザーがコンテンツをスクロールするにつれて再利用される画面上の固定数のDOM要素のみを持つことで、この問題を完全に回避します。
何か誤解していたら訂正してください。
よろしくお願いします、
Spirobel :grinning:

「いいね!」 2