Enterprise: Dropdown/Multiselect: Refactoring zur Verwendung eines Datenquellenobjekts im Gegensatz zu einem Select-Element

HINWEIS: Dieses Problem behebt möglicherweise einige Leistungsprobleme, die in #843 (und anderen) identifiziert wurden.

Bezieht sich Ihre Feature-Anfrage auf ein Problem?
Das aktuelle Dropdown/Multiselect, das wir mit IDS ausliefern, wurde als Interaktionsebene über dem Standard-HTML-Element <select> erstellt, das die Auswahl seiner Optionen sowohl in Einzel- als auch in Mehrfacheinstellungen handhabt.

Die Anwendungsfälle für diese Komponente haben sich im Laufe der Zeit erweitert, um das Filtern der verfügbaren Optionen einzuschließen, was dazu geführt hat, dass Teams das Dropdown/Multiselect für extrem große Datensätze verwenden (in einigen Fällen mehr als 2000 Elemente gleichzeitig). Obwohl unser Team festhält, dass wir die Verwendung dieser Komponente für Datensätze dieser Größe nicht empfehlen, erhalten wir weiterhin Probleme, die uns dazu auffordern, die Leistung auf diesen Ebenen anzugehen. Zu den früheren Problemen, die wir behoben haben, gehören:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 ist die neueste

Viele dieser Probleme lassen den Vorbehalt "das ist immer noch nicht großartig, aber es ist besser". Der Grund dafür ist, dass sich das Design des Dropdown/Multiselect im Kern nicht gut für so große Datensätze eignet. Wenn wir Leistungsprobleme beheben wollen, müssen wir uns mit den Grundlagen seines Designs befassen.

Beschreiben Sie die gewünschte Lösung
Ein möglicher Lösungsweg zur Behebung der Performance von Dropdown/Multiselect:

• [ ] Eine strenge Voraussetzung für die Verwendung von <select> als primäre Datenquelle. Einige neuere Verbesserungen aus Nr. 267 begannen zu zeigen, wie ein AJAX-Aufruf ein Datenobjekt für Dropdown generieren könnte, das wir auf dem Client speichern können. Ich denke, wir sollten dazu übergehen, ein Objekt mit einigen einfachen Zuständen (deaktiviert/ausgewählt/usw.) als primären Treiber für das Verhalten der Komponente zu verwenden, anstatt diese Informationen aus einem DOM-Element zu holen. Das Rendern des <select> -Tags und seiner <option> -s wird immer noch für Dinge wie das Absenden von Formularen notwendig sein, aber wir sollten das Datenobjekt als "Quelle der Wahrheit" definieren und das select-Tag zeichnen abhängig vom Objekt (nicht umgekehrt).
• [ ] Erforschen Sie auch einfach keine Abhängigkeit von einem <select> -Tag in irgendeiner Weise. Es kann ein vernünftiger Anwendungsfall für einen Entwickler sein, der Dropdown/Multiselect mit so vielen Elementen verwendet, um eine Anfrage zur Formularübermittlung einfach abzufangen und den Status des Datenquellenobjekts zu senden, anstatt sich auf den normalen Formularübermittlungsprozess zu verlassen. Derzeit ist diese Art der Nutzung nicht möglich.
• [ ] Sobald wir uns nicht mehr auf das DOM-Element verlassen, können wir damit beginnen, nur eine Teilmenge von Listenelementen im DOM zu einem bestimmten Zeitpunkt anzuzeigen. Da der Status vom Datenquellenobjekt beibehalten wird, spielt das DOM nicht unbedingt eine Rolle, und es sollte viel trivialer sein, kleine Mengen von Listenelementen zu laden/entladen, während ein Benutzer durch eine Liste scrollt (würde es uns ermöglichen, #460 weiter zu erkunden Dropdown-Liste).
• [ ] Erstellen Sie bessere Empfehlungen für die serverseitige Handhabung großer Datensätze. Selbst das Beibehalten des Zustands in einem clientseitigen Objekt mit so vielen Datensätzen kann schließlich sehr langsam werden. Wir möchten vielleicht eine Empfehlung und/oder einige Demos haben, wie wir Implementierungen von IDS wünschen könnten, um Dropdown/Multiselect-Datensätze auf dem Server zu handhaben.

Beschreiben Sie Alternativen, die Sie in Betracht gezogen haben
Einige andere Ideen, die wir in der Vergangenheit vorgestellt haben:

• Eine einfachere Komponente, die <select> -Tags überlagert und formatiert, anstatt Pseudo-Markups für Interaktionen zu generieren. Dies könnte die größere Liste möglicherweise besser handhaben, da sie nicht dupliziert würde. Wir müssten in diesem Fall immer noch 2000 Elemente auf einmal handhaben.