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 최신

이러한 문제 중 많은 부분이 "아직 좋지는 않지만 더 좋습니다"라는 경고를 남깁니다. 그 이유는 핵심에 있는 Dropdown/Multiselect의 디자인이 이렇게 큰 데이터 세트에 적합하지 않기 때문입니다. 성능 문제를 해결하려면 설계의 기본 사항을 해결해야 합니다.

원하는 솔루션 설명
Dropdown/Multiselect의 성능을 수정하기 위한 가능한 솔루션 경로:

• [ ] <select> 를 기본 데이터 소스로 사용해야 하는 까다로운 요구 사항입니다. #267의 최근 개선 사항은 AJAX 호출이 클라이언트에 저장할 수 있는 드롭다운에 대한 데이터 개체를 생성하는 방법을 매핑하기 시작했습니다. DOM 요소에서 이 정보를 가져오는 대신 구성 요소 동작의 기본 드라이버로 몇 가지 간단한 상태(비활성화/선택됨/등)를 가진 개체를 사용하는 방향으로 나아가야 한다고 생각합니다. <select> 태그 및 해당 <option> 의 렌더링은 양식 제출과 같은 작업에 여전히 필요하지만 데이터 개체를 "진실의 소스"로 정의하고 선택 태그를 그려야 합니다. 객체를 기반으로 합니다(반대 아님).
• [ ] 또한 <select> 태그에 어떤 의미로든 렌더링/종속성이 없는지 살펴보십시오. 개발자가 이 많은 항목과 함께 드롭다운/다중 선택을 활용하여 양식 제출 요청을 단순히 가로채고 일반 양식 제출 프로세스에 의존하는 대신 데이터 소스 개체의 상태를 보내는 것이 합리적인 사용 사례일 수 있습니다. 현재 이러한 유형의 사용은 불가능합니다.
• [ ] DOM 요소에 더 이상 의존하지 않으면 주어진 시간에 DOM에 있는 목록 항목의 하위 집합만 표시하는 탐색을 시작할 수 있습니다. 상태가 데이터 소스 객체에 의해 유지되기 때문에 DOM은 반드시 중요하지 않으며 사용자가 목록을 스크롤할 때 소량의 목록 항목을 로드/언로드하는 것이 훨씬 더 간단해야 합니다. 쓰러지 다).
• [ ] 대용량 데이터 세트의 서버 측 처리에 대한 더 나은 권장 사항을 만듭니다. 많은 레코드가 있는 클라이언트 측 개체에서 상태를 유지하는 것조차 결국에는 매우 느려질 수 있습니다. IDS 구현이 서버에서 드롭다운/다중 선택 레코드를 처리하는 방법에 대한 권장 사항 및/또는 일부 데모가 필요할 수 있습니다.

고려한 대안을 기술하십시오
우리가 과거에 떠오른 몇 가지 다른 아이디어:

• 상호 작용을 위한 의사 마크업을 생성하는 대신 <select> 태그를 오버레이하고 스타일을 지정하는 더 간단한 구성 요소입니다. 이것은 중복되지 않기 때문에 더 큰 목록을 더 잘 처리할 수 있습니다. 이 경우 여전히 2000ish 요소를 한 번에 처리해야 합니다.