ツリーの予想されるページング動作は何ですか？
私は視覚化する必要があるツリーデータ構造を使用しています（ファイルマネージャーなど）。
サーバーはツリー全体を計算でき、クライアントはそれを表示します。
可能なツリーのサイズは、クライアントが一度にすべてを処理するには大きすぎる可能性があるため、「開いた」ノードの子ノードのみを要求します。
しかし、非常に多くの子ノードが存在する可能性があり、それらすべてがクライアントを強制終了する可能性があります。したがって、ページングの方法が必要ですが、ユーザーが期待するページング動作がどれかわかりません。
クライアント上のキャッシュデータを最小限に抑え、クライアントが「遠く離れたノード」（134/200ページ）にすばやくアクセスできるようにする必要があります。
実際には、UXに適さない2つの要素、つまりツリー構造とページネーションを組み合わせながら、より良いインタラクションデザインを確保する方法を尋ねています。
1.ツリー構造
残念ながら、階層ツリーは、ツールボックスで最も不適切に使用されるコントロールの1つです。これらはユーザーにとって非常に問題になる可能性があります。多くの人々は、階層データ構造の観点から考えるのが困難です。
Face 3、The Essentials of Interaction Design、Alan Cooper、Robert Reimann and David Cronin、ISBN 978-0-470-08411-3、p。 457。
木構造は1989年に人気がありました。今日、ツリー構造のほとんどすべての使用法は、UXの観点からみて混乱しています。
最も身近な例の1つであるファイルシステムは混乱です。通常のユーザーがファイルを管理する必要がないという事実は別として、ファイルがツリーとして表示されるという事実は事態をさらに悪化させます。
別の例として、掲示板（フォーラム） これもめちゃくちゃです です。 Stack Exchangeは、物事が正しく行われる方法を非常によく示しています。見る？カテゴリもツリー構造もありませんが、タグと検索が必要です。
データを視覚化するためにツリーを使用する非常に深刻な理由がない限り（そして、めったに使用しません）、実際のユーザーが実際に使用できる視覚化に切り替えます。
2.ページネーション
10、50、100、多分数百のアイテムがある場合に、ページ付けを理解できます。しかし、ページ分割するアイテムが何千もあるとしたら、一体誰が3810の964ページにアクセスしているのでしょうか。
The End of Pagination 、Jeff Atwood、コーディングホラーブログ。
最初に、ページネーションを置き換えるより新しい、より良い代替案があります。オンデマンドで追加のレコードを入力する（Jeffによってendless paginationと呼ばれますが、ページネーションではないため、名前の選択を批判します）。代替。 Google画像はそのようなパターンの有名な例です。
第二に、あなたはあなたの質問で「200ページの200ページ」について話します。 200ページのうち134ページにアクセスするのは誰ですか（Jeffの投稿を参照）。データを視覚化するためにユーザーが見つけた唯一の方法ですか？
実例1
写真をホストするWebアプリを作成するとします。たくさんの写真。それらの写真は分類され、木の形で提示されます。たとえば、ソファで寝ている黒い猫の写真は次のようになります。
Animals
→ Domestic animals
→ Cats
→ Sleeping cats
→ Black cats
「黒猫の眠り」カテゴリには、1538他の写真も含まれています。
木を使用することは適切ですか？実際、これは最も恐ろしい方法です。ツリーを作成すると、ユーザーがデータを一度に検索、視覚化、操作することがほとんど不可能になります。
どれどれ。下のツリーを考えると、黒猫のすべての写真を検索したいと思います。どのように進めますか？最初に、私はに行く必要があります：
動物→家畜→猫→眠っている猫→黒い猫
次に：
動物→家畜→猫→猫と遊ぶ→黒い猫
次に：
動物→家畜→猫→走っている猫→黒い猫
それから他の何十ものカテゴリーに。黒い家畜の写真を見たいのですが？または黒い動物？ 最も単純なシナリオでWebアプリがどのように使用できないのかを確認してください
しかし、まあ、私が眠っている黒い猫を探していたとしましょう。そのため、調べなければならないカテゴリは1つだけです。中には、最初の10枚の写真があり、154ページの写真があることがわかりました。 114ページに行くと思いますか？なぜですか？とても便利でしょうか？最初の2、3ページと比べて114ページの違いは何ですか？
ツリー構造をタグと強力な検索に置き換え、ページングをオンデマンドで追加のレコードに入力する機能で想像してみてください。よく見える？
ご覧のように、ツリー構造とページ分割の両方がデータを表示するための最悪の方法であり、アプリケーションを無価値にして使用できなくなります。
実例2
別のケースを想像してみましょう。静的HTTPサーバーログを表示するアプリを作成しています。すべてのファイル（→ツリー構造）には、要求の日付と時刻、要求パラメーター、応答のサイズなどを含む多数のエントリがあります。単一のファイルが数千回（→ページネーション）。
木を使用することは適切ですか？ companyLogo300x150WhiteBg.pngに対するリクエストを視覚化したいとします。どこにあるか覚えていません。パスは気にしません。パスを確認するためだけにブラウザーに開発者ツールを表示したくないし、HTTPサーバーでパスを検索するのに数分も費やしたくない。 ファイルの名前はすでに知っていますが、なぜこれで十分ではないのですか？なぜこの愚かなアプリは、自分自身でファイルの場所を特定するのではなく（木を歩く）、愚かなことをするように求めます（検索）]
ページネーションを使用することは適切ですか？なぜログレコードを見たいのですか？
ファイルが時間の経過とともにどのようにリクエストされたかを確認する。たとえば、会社のロゴファイルが1か月前に1時間あたり数百回リクエストされたが、Webサイトが
companyLogo300x150WithAlpha.pngに移動したため、現在はほとんど使用されていないことを発見したいと思います。この場合、未加工のページ付けされた結果は、想像できる最も貧弱な視覚化方法です。時間の経過に伴うリクエスト数を示すグラフの方がはるかに優れています。
誰がいつファイルにアクセスしたかを確認する。
この場合も、ページ分割された生の結果は実用的ではなく、グラフやフィルターを使用してデータを表示するためのより良い方法を考え出す必要があります。
ご覧のとおり、ツリー構造とページ分割の両方がデータを表示するための最悪の方法であり、アプリケーションを価値がなく、使用できなくなります。
注意してください：あなたはそれを言う：
しかし、非常に多くの子ノードが存在する可能性があり、それらすべてがクライアントを強制終了する可能性があります。
多くのエンティティをユーザーに表示することは決して良い考えではありません。 人間の脳は視覚化によって一度に限られた量の情報を処理できます。 2,000のエントリを含むチャートを人に見せた場合（大きなモニターがあるとすると、各エントリは1ピクセルの大きさで、一度にすべてを表示できるため、あまり役に立ちません。 10個の連続するエントリを平均で1つにグループ化することにより、最小値と最大値を確認するのがはるかにきれいになります。
平均的なデバイスを持っている人が大量のデータを処理できるかどうかを自問するときは、このデータの提示方法について考えてください。
使用されていないルートノードを単に折りたたんでみませんか？それでもスコープが十分に縮小されない場合は、すべてのルートノードと、使用中の子ノードを除くすべての第1レベルの子ノードを折りたたみます。
ノードを開くときに動的にロードし、同じランクの他のノードを折りたたむことができます。