アイデアを簡単に紹介します。
オブジェクトに ajax を適用し、次に 子から親へ オブジェクトを順番に作成し、スタイルを設定し、レベルを追加します。
コードは次のようになります:
こんなことばかり。 。 。最適化するにはどうすればよいですか?
ES6 のフロントエンドのサポートが理想的ではないため、文字列テンプレートが使用できず、フレームワークの追加も困難です。ハードウェアの場合はどうすればよいですか?
文字列を連結してから直接 innerHTML を使用する場合と比較して、このように記述する場合の欠点は何ですか?
まず、JS人間がDOMを保守するために使用する【手続き型プログラミング】は、保守性の点でテンプレート型の【宣言型プログラミング】に比べて劣ります。
<p>xxx</p>
和一大坨document.createElement('p')...
の単純な行を考えてみましょう。保守性に大きな違いが生じます。それでは、ES6 やさまざまなフレームワークの構文糖を使用せずに、文字列テンプレートと同様の方法を使用してデータを HTML にバインドするにはどうすればよいでしょうか?これは、jQuery の作者がかつて推奨した解決策です:
まず、HTMLで外部に卑猥な
リーリー<script>
标签装模板,注意这个模板本身对 JS 并没有任何依赖,也可以把模板放在<body>
を作ることができます。データをレンダリングするときは、テンプレート内の HTML テキストを直接取り出し、JS を使用して定期的に置換します。
リーリー私のこのブログを参照してください:
http://ewind.us/2016/js-rende...
もちろん、innerHTML を完全にリセットすると、パフォーマンスのリスクが伴います。ただし、データが完全に更新されている場合は、コードがネイティブ JS で記述されている場合でも、最終的な DOM 操作の数は実際には innerHTML を直接リセットする場合と同じになります。現時点ではいくつかのアイデアがあります:
React はこの種の問題のために生まれました。 React を innerHTML として考えて、すべてを自由にリセットすれば、必要に応じて React が DOM の差分や更新を支援してくれると思いませんか。
Vue は依存関係コレクションを使用して、変更された DOM の場所を直接見つけて、必要に応じて更新します。diff も使用せず、それがどの程度高度であるかはわかりません。
ビジネスニーズを満たす diff アルゴリズム (最後にのみ挿入するなど) と DOM 操作を保守します。もしかしたらそれは新たなホイール誕生の序曲かも知れません(
構造が複雑すぎて、洗練されておらず、純粋に物理的な抵抗があり、デバッグは単なる悪夢です。将来的にはコードのメンテナンスが多すぎるでしょう。
JS ファイルを導入するだけのフロントエンド JS テンプレート エンジン (例: artTemplate) を使用することをお勧めします。
最も単純な利点: innerHTML より高速です。
これらの構造を一度に数百個追加すると、明らかな速度の違いを体験できます