JavaScript를 사용하여 그리드에 사용자에게 많은 수의 데이터 행 (예 : 수백만 행)을 제시해야합니다.
사용자는 한 번에 페이지를 보거나 유한 한 양의 데이터 만 보지 않아야합니다.
오히려 모든 데이터를 사용할 수있는 것으로 보입니다.
데이터를 한 번에 모두 다운로드하는 대신 작은 청크는 사용자가 올 때 (즉, 그리드를 스크롤하여) 다운로드됩니다.
이 프런트 엔드를 통해 행을 편집 할 수 없으므로 읽기 전용 그리드를 사용할 수 있습니다.
이러한 원활한 페이징을 위해 JavaScript로 작성된 데이터 그리드는 무엇입니까?
답변
( 면책 조항 : 저는 SlickGrid의 저자입니다 )
업데이트
이제 SlickGrid 에서 구현되었습니다 .
SlickGrid가 더 많은 행에서 작동하도록하는 방법에 대한 지속적인 논의는 http://github.com/mleibman/SlickGrid/issues#issue/22 를 참조하십시오 .
문제는 SlickGrid가 스크롤 막대 자체를 가상화하지 않는다는 것입니다. 스크롤 가능 영역의 높이는 모든 행의 총 높이로 설정됩니다. 사용자가 스크롤 할 때 행이 계속 추가되고 제거되지만 스크롤 자체는 브라우저에서 수행됩니다. 그것은 매우 빠르지 만 매끄 럽습니다 (onsroll 이벤트는 악명 높음). 주의 사항은 브라우저의 CSS 엔진에 요소의 잠재적 높이를 제한하는 버그 / 제한이 있다는 것입니다. IE의 경우 0x123456 또는 1193046 픽셀입니다. 다른 브라우저의 경우 더 높습니다.
“largenum-fix”브랜치에는 “페이지”를 1M 픽셀 높이로 설정 한 상태에서 스크롤 가능 영역을 채우고 해당 페이지 내에서 상대 위치를 사용하여 한계를 크게 높이는 실험적인 해결 방법이 있습니다. CSS 엔진의 높이 제한은 실제 레이아웃 엔진과는 다르고 상당히 낮은 것으로 보이므로 상한이 훨씬 더 높습니다.
SlickGrid가 현재 다른 구현보다 우수한 성능을 포기하지 않으면 서 행을 무제한으로 늘릴 수있는 방법을 찾고 있습니다.
Rudiger,이 문제를 어떻게 해결했는지 자세히 설명해 주시겠습니까?
답변
https://github.com/mleibman/SlickGrid/wiki
” SlickGrid는 가상 렌더링을 사용하여 성능 저하없이 수십만 개의 항목으로 쉽게 작업 할 수 있습니다. 실제로 10 행이있는 그리드 작업과 100’000 행의 작업 사이에는 성능 차이가 없습니다. “
일부 주요 특징 :
- 적응 형 가상 스크롤 (수십만 행 처리)
- 매우 빠른 렌더링 속도
- 더 풍부한 셀을위한 백그라운드 포스트 렌더링
- 구성 및 사용자 정의 가능
- 전체 키보드 탐색
- 열 크기 조정 / 재주문 / 표시 / 숨기기
- 컬럼 자동 크기 조정 및 강제 맞춤
- 플러그 형 셀 포맷터 및 편집기
- 새 행 편집 및 작성을 지원합니다. “by mleibman
무료입니다 (MIT 라이센스). jQuery를 사용합니다.
답변
내 의견으로는 최고의 그리드는 다음과 같습니다.
- Flexigrid : http://flexigrid.info/
- jQuery 그리드 : http://www.trirand.com/blog/
- jqGridView : http://plugins.jquery.com/project/jqGridView
- jqxGrid : http://www.jqwidgets.com/
- 잉그리드 : http://reconstrukt.com/ingrid/
- SlickGrid http://github.com/mleibman/SlickGrid
- DataTables http://www.datatables.net/index
- ShieldUI http://demos.shieldui.com/web/grid-virtualization/performance-1mil-rows
가장 좋은 3 가지 옵션은 jqGrid, jqxGrid 및 DataTables입니다. 수천 개의 행으로 작업하고 가상화를 지원할 수 있습니다.
답변
나는 화염 전쟁을 시작한다는 의미는 아니지만, 연구자들이 인간이라고 가정하면, 당신은 그들이 생각하는 것만 큼 잘 모른다. 그들은 그냥 있기 때문에 이 페타 바이트의 데이터를 의미있는 방식으로 기록의 수백만을 보는 그들이 할 수하지 않습니다. 그들은 수백만 개의 레코드를보고 싶다고 말할 수도 있지만 그것은 어리석은 일입니다. 가장 현명한 연구원이 기본적인 수학을하도록하십시오. 각 기록을 1 초씩 보는 것으로 가정하십시오. 이 속도에서 1000000 초가 걸리고 6 주 이상 (음식 또는 화장실에 휴식을 취하지 않는 주당 40 시간의 노동 시간)까지 진행됩니다.
그들이 (또는 당신) 진심으로 한 사람 (그리드를보고있는 사람)이 그런 종류의 집중력을 발휘할 수 있다고 생각합니까? 그들은 실제로 1 초 안에 많은 일을 하고 있습니까, 아니면 원하지 않는 것들을 걸러 낼 가능성 이 있습니까? “합리적인 크기의”하위 집합을 본 후 해당 레코드를 자동으로 필터링하는 필터를 설명 할 수 있다고 생각합니다.
paxdiablo와 Sleeper Smith 및 Lasse V Karlsen도 암시했듯이 귀하 (및 그들)는 요구 사항을 고려하지 않았습니다. 위쪽에서 SlickGrid를 찾았으므로 해당 필터의 필요성이 즉시 명백해졌습니다.
답변
나는 당신에게 심각하게 사용자에게 수백만 행의 데이터를 보여줄 필요가 없다고 확실히 말할 수 있습니다.
전 세계에 해당 데이터 세트를 이해하거나 관리 할 수있는 사용자가 없으므로 기술적으로 데이터를 가져 오더라도 해당 사용자에 대해 알려진 문제는 해결되지 않습니다.
대신 사용자가 왜 데이터를보고 싶어 하는지에 초점을 맞출 것 입니다. 사용자는 단지 데이터를보기 위해 데이터를보고 싶지 않으며, 일반적으로 질문이 있습니다. 그 질문에 대답하는 데 집중한다면 실제 문제를 해결하는 것에 훨씬 더 가까워 질 것입니다.
답변
버퍼링 뷰 기능이있는 Ext JS Grid를 권장합니다.
답변
(면책 조항 : 나는 w2ui의 저자입니다)
최근에 100 만 개의 레코드를 가진 JavaScript 그리드를 구현하는 방법에 대한 기사를 작성했습니다 ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). 나는 궁극적으로 그것을 더 높이 가져 가지 못하게하는 3 가지 제한 사항이 있음을 발견했습니다.
- div의 높이에는 한계가 있습니다 (가상 스크롤로 극복 가능)
- 1 백만 레코드 정도 후에 정렬 및 검색과 같은 작업이 느리게 시작됩니다.
- 데이터가 JavaScript 배열에 저장되므로 RAM이 제한됩니다
IE를 제외하고 1 백만 개의 레코드로 그리드를 테스트했으며 제대로 수행합니다. 데모 및 예제는 기사를 참조하십시오.