レンダリング

この章は、リアクティブな状態が変化してから画面上のピクセルが更新されるまでに何が起こるかについてです。それを考える必要はめったにありません——ですがモデルを理解すれば、なぜ $mol のコードが特別な努力なしに高速なままなのかがわかります。

仮想 DOM なし

$mol は仮想ツリーの差分を取りません。各ビューのプロパティは、

状態ですでに出会ったのと同じリアクティブなセルを通じて、それが制御する DOM ノードや属性に直接束ねられます。セルが変化すると、それを読むまさにその束縛だけが再実行されます——部分木でも、コンポーネント関数でもなく、影響を受けたプロパティだけです。つまり、最適化すべき調停パスはなく、リストの差分のために手で調整するキーもなく、頼るべき memo/shouldComponentUpdate もありません。依存グラフはすでに最小の更新集合を知っています。

コンポーネントは遅延評価

ビューは、何かがそれを要求したときにだけ構築されます。一度も遷移しない画面は決して構築されず、一度も開かないタブは何のコストもかかりません。構築はオンデマンドでキャッシュされるので、大きなコンポーネントツリーを組み立てるのは安価です——必要のない部分は、まだ存在しないだけです。

レンダリングは仮想化されている

$mol はビューポート内にあるものだけを描画します。視界の外へスクロールされたコンポーネントは隠された DOM として保持されません——まったく作成されず、範囲へスクロールしてきた瞬間に構築されます。これはフレームワークのアーキテクチャ上の性質であって、オプトインの機能でも特別なリストコンポーネントでもありません。あらゆるレイアウトが仮想化されるので、10 項目のリストと 1 万項目のリストは表示コストがほぼ同じです。実際の効果として、ウィンドウ化ライブラリに頼らずに、ふつうのコンポーネントツリーや長いリストを書けます。

再現可能な数字

性能の主張は、再現できてはじめて役に立ちます。ここで数字を挙げる代わりに、$mol はコミュニティの js-framework-benchmark に参加しています。その結果を読み、スイートを自分で再実行できます。

js-framework-benchmark の結果それを比較の信頼できる情報源として扱ってください——測定され、バージョン管理され、このページから独立しています。

これで $mol の動作の中核モデルは完成です。次は、

データ取得で実際のデータを読み込ませて働かせましょう。GitHub でこのページを編集役に立ちましたか？はいいいえ前へルーティング次へテストこのページの内容仮想 DOM なしコンポーネントは遅延評価レンダリングは仮想化されている再現可能な数字次へ