Enterprise: Dropdown/Multiselect: refatorar para usar um objeto de fonte de dados em oposição a um elemento Select

NOTA: Este problema potencialmente resolve alguns problemas de desempenho identificados em #843 (e outros).

Sua solicitação de recurso está relacionada a um problema?
O atual Dropdown/Multiselect que enviamos com o IDS foi criado como uma camada de interação sobre o elemento HTML padrão <select> , manipulando a seleção de suas opções em configurações simples/múltiplas.

Os casos de uso para este componente aumentaram ao longo do tempo para incluir a filtragem das opções disponíveis, o que levou as equipes a usar o menu suspenso/multiseleção para conjuntos de dados extremamente grandes (superando mais de 2.000 itens por vez, em alguns casos). Embora nossa equipe afirme que não recomendamos o uso desse componente para conjuntos de dados tão grandes, continuamos a ter problemas solicitando que abordemos o desempenho nesses níveis. Alguns problemas anteriores que corrigimos incluem:

• https://jira.infor.com/browse/SOHO-5693
• https://jira.infor.com/browse/SOHO-5192
• https://jira.infor.com/browse/SOHO-7816
• #843 sendo o mais recente

Muitas dessas questões deixam a ressalva de "isso ainda não é ótimo, mas é melhor". A razão para isso é porque o design do Dropdown/Multiselect em seu núcleo não se adapta bem a conjuntos de dados tão grandes. Se quisermos corrigir problemas de desempenho, precisamos abordar os fundamentos de seu design.

Descreva a solução que você deseja
Um possível caminho de solução para corrigir o desempenho do Dropdown/Multiselect:

• [ ] Um requisito difícil de usar <select> como a fonte de dados primária. Algumas melhorias recentes de #267 começaram a mapear como uma chamada AJAX pode gerar um objeto de dados para Dropdown que podemos armazenar no cliente. Acho que devemos avançar para o uso de um objeto com alguns estados simples (desativado/selecionado/etc) como o principal driver do comportamento do componente, em vez de pegar essas informações de um elemento DOM. A renderização da tag <select> e seus <option> s ainda serão necessários para coisas como envio de formulários, mas devemos definir o objeto de dados como a "fonte da verdade" e desenhar a tag select com base no objeto (não vice-versa).
• [ ] Explore também simplesmente não renderizar/ter uma dependência de uma tag <select> em nenhum sentido. Pode ser um caso de uso razoável para um desenvolvedor que utiliza o Dropdown/Multiselect com tantos itens para simplesmente interceptar uma solicitação de envio de formulário e enviar o estado do objeto de fonte de dados em vez de depender do processo normal de envio de formulário. Atualmente, esse tipo de uso não é possível.
• [ ] Uma vez que não dependemos mais do elemento DOM, podemos começar a explorar apenas a exibição de um subconjunto de itens de lista no DOM a qualquer momento. Como o estado é retido pelo objeto de fonte de dados, o DOM não importa necessariamente, e deve ser muito mais trivial carregar/descarregar pequenas quantidades de itens de lista à medida que um usuário percorre uma lista (nos permitiria explorar #460 em Suspenso).
• [ ] Crie recomendações melhores para o manuseio de grandes conjuntos de dados no lado do servidor. Mesmo reter o estado em um objeto do lado do cliente com tantos registros pode, eventualmente, ficar muito lento. Podemos querer ter uma recomendação e/ou algumas demonstrações de como podemos querer que as implementações do IDS lidem com os registros Dropdown/Multiselect no servidor.

Descreva as alternativas que você considerou
Algumas outras ideias que já sugerimos no passado:

• Um componente mais simples que sobrepõe as tags <select> e as estiliza, em vez de gerar pseudo-marcações para interações. Isso pode ser capaz de lidar melhor com a lista maior, pois não a duplicaria. Ainda teríamos que lidar com 2.000 elementos de uma só vez neste caso.