Enterprise: ドロップダウン/複数選択：Select要素ではなくデータソースオブジェクトを使用するようにリファクタリング

注：この問題は、＃843（およびその他）で特定されたいくつかのパフォーマンスの問題に対処する可能性があります。

機能リクエストは問題に関連していますか？
IDSに同梱されている現在のドロップダウン/マルチセレクトは、標準のHTML <select>要素の上にインタラクションレイヤーとして作成され、単一/複数の設定の両方でオプションの選択を処理します。

このコンポーネントのユースケースは、利用可能なオプションのフィルタリングを含むように時間の経過とともに増加しました。これにより、チームは非常に大きなデータセットにドロップダウン/マルチセレクトを使用するようになりました（場合によっては、一度に2000を超えるアイテムを超える）。 私たちのチームは、これほど大きなデータセットにこのコンポーネントを使用することはお勧めしませんが、これらのレベルでのパフォーマンスに対処することを要求する問題が引き続き発生します。 以前に修正した問題には、次のものがあります。

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• ＃843が最新

これらの問題の多くは、「これはまだ素晴らしいことではありませんが、より良い」という警告を残しています。 これは、ドロップダウン/マルチセレクトの設計が、これほど大きなデータセットには適していないためです。 パフォーマンスの問題を修正したい場合は、その設計の基本に取り組む必要があります。

希望するソリューションを説明してください
ドロップダウン/マルチセレクトのパフォーマンスを修正するための可能なソリューションパス：

• []プライマリデータソースとして<select>を使用するという厳しい要件。 ＃267からの最近のいくつかの改善により、AJAX呼び出しがクライアントに保存できるドロップダウンのデータオブジェクトを生成する方法が明らかになり始めました。 DOM要素からこの情報を取得するのではなく、コンポーネントの動作の主要なドライバーとして、いくつかの単純な状態（無効/選択など）を持つオブジェクトの使用に移行する必要があると思います。 <select>タグとその<option>のレンダリングは、フォームの送信などには引き続き必要ですが、データオブジェクトを「真実のソース」として定義し、selectタグを描画する必要があります。オブジェクトに基づいています（その逆ではありません）。
• []また、いかなる意味でも<select>タグに依存しない/レンダリングしないことを検討してください。 ドロップダウン/マルチセレクトをこのように多くのアイテムとともに利用して、フォーム送信のリクエストをインターセプトし、通常のフォーム送信プロセスに依存する代わりにデータソースオブジェクトの状態を送信することは、開発者にとって合理的なユースケースかもしれません。 現在、このタイプの使用はできません。
• [] DOM要素に依存しなくなったら、いつでもDOM内のリストアイテムのサブセットのみを表示することを検討し始めることができます。 状態はデータソースオブジェクトによって保持されるため、DOMは必ずしも重要ではなく、ユーザーがリストをスクロールするときに少量のリストアイテムをロード/アンロードする方がはるかに簡単です（＃460を探索できるようになります）落ちる）。
• []大規模なデータセットのサーバー側処理に関するより適切な推奨事項を作成します。 その数のレコードを持つクライアント側オブジェクトの状態を保持することでさえ、最終的には非常に遅くなる可能性があります。 IDSの実装でサーバー上のドロップダウン/複数選択レコードを処理する方法の推奨事項やデモが必要になる場合があります。

検討した代替案を説明してください
私たちが過去に浮かんだ他のいくつかのアイデア：

• インタラクションの疑似マークアップを生成する代わりに、 <select>タグをオーバーレイしてスタイルを設定する、より単純なコンポーネント。 これにより、リストが複製されないため、より大きなリストをより適切に処理できる可能性があります。 この場合でも、一度に2000個の要素を処理する必要があります。