Kisi data JavaScript untuk jutaan baris [ditutup]


225

Saya perlu menyajikan sejumlah besar baris data (mis. Jutaan baris) kepada pengguna dalam kotak menggunakan JavaScript.

Pengguna seharusnya tidak melihat halaman atau hanya melihat data dalam jumlah terbatas pada suatu waktu.

Sebaliknya, akan muncul bahwa semua data tersedia.

Alih-alih mengunduh data sekaligus, potongan kecil diunduh saat pengguna datang kepada mereka (mis. Dengan menggulir melalui grid).

Baris tidak akan diedit melalui ujung depan ini, jadi grid hanya baca dapat diterima.

Kisi data apa, yang ditulis dalam JavaScript, ada untuk jenis paging tanpa batas ini?


1
Saya tidak menerima jawaban jqgrid, karena tampaknya gagal untuk kumpulan data besar ... Ada saran lain? Bagaimana dengan ext-livegrid.com ?
Rudiger

6
Tulis milikmu sendiri. Saya yakin yang lain tersedak karena mereka terus menambahkan ke DOM. Saya pikir Anda akan membutuhkan solusi yang Menghapus baris karena mereka gulir off layar. Hanya itu caranya. Anda tidak dapat memiliki sejuta baris tabel di DOM dan mengharapkan setiap browser menampilkan dan menggulir dengan mulus di setiap lingkungan. Masuk akal.
Josh Stodola

2
@Rudiger: SlickGrid sekarang mendukung jumlah baris yang tidak terbatas secara asli. Lihat github.com/mleibman/SlickGrid/tree/unlimited-rows . Setelah ini diuji secara menyeluruh itu akan digabungkan ke cabang utama.
Timah

10
Dan saya merasa menyesal perusahaan mana yang Anda bekerja. Sebagai informasi, layar 1920x1080 dengan hanya 1 juta baris ditampilkan, akan melompati 20 baris untuk setiap satu piksel gerakan pada bilah gulir. Pergi lakukan beberapa pengujian kegunaan alih-alih membuang-buang waktu Anda.
Sleeper Smith

2
Pertanyaan ini dan dua jawaban teratasnya (setidaknya) sangat berguna. Mungkin menarik beberapa jawaban berkualitas rendah, tetapi tidak berarti pertanyaan ini harus Ditutup. Menggunakan SlickGrid untuk menyelesaikan masalah ini dapat menghemat banyak masalah dan kesulitan pengkodean orang, jika mereka mencoba mengimplementasikannya sendiri.
Sam Watkins

Jawaban:


190

( Penafian: Saya penulis SlickGrid )

PEMBARUAN Ini sekarang telah diterapkan di SlickGrid .

Silakan lihat http://github.com/mleibman/SlickGrid/issues#issue/22 untuk diskusi berkelanjutan tentang membuat SlickGrid berfungsi dengan jumlah baris yang lebih banyak.

Masalahnya adalah bahwa SlickGrid tidak memvirtualisasikan scrollbar itu sendiri - ketinggian area yang dapat digulir diatur ke tinggi total semua baris. Baris masih ditambahkan dan dihapus saat pengguna sedang menggulir, tetapi pengguliran itu sendiri dilakukan oleh browser. Itu memungkinkan untuk menjadi sangat cepat namun lancar (acara onroll sangat terkenal lambat). Peringatannya adalah bahwa ada bug / batas dalam mesin CSS browser yang membatasi ketinggian potensial suatu elemen. Untuk IE, itu adalah 0x123456 atau 1193046 piksel. Untuk browser lain, ini lebih tinggi.

Ada solusi eksperimental di cabang "fix-fix" yang meningkatkan batas itu secara signifikan dengan mengisi area yang dapat digulir dengan "halaman" yang diatur ke ketinggian 1M piksel dan kemudian menggunakan posisi relatif di dalam halaman tersebut. Karena batas ketinggian di mesin CSS tampaknya berbeda dan jauh lebih rendah daripada di mesin tata letak yang sebenarnya, ini memberi kita batas atas yang jauh lebih tinggi.

Saya masih mencari cara untuk mendapatkan jumlah baris yang tidak terbatas tanpa melepaskan keunggulan kinerja yang saat ini dimiliki SlickGrid atas implementasi lainnya.

Rudiger, dapatkah Anda menjelaskan bagaimana Anda memecahkan ini?


1
Saya telah menemukan SlickGrid sebagai yang paling menarik - terutama jika seseorang bekerja dengan jQuery. Selamat! (terutama untuk sikap dan kegigihan yang hebat.) :-)
Andras Vass

Saya mencoba menggunakan slickgrid untuk menampilkan header excel, dan saya melihat bahwa ketika memiliki terlalu banyak kolom, slickgrid hanya mengoptimalkan pengguliran baris dan bukan kolom. Saya juga memperhatikan bahwa ketika memiliki lebih dari 120 kolom atau lebih - slickgrid menempatkan baris baru di baris baru. Bisakah jumlah baris maksimum ditetapkan di suatu tempat di file?
oneiros

1
SlickGrid v2.1 telah menggunakan pengguliran virtual untuk kolom dan juga baris. Juga, masalah kolom yang meluap telah diatasi.
Timah

@ Tin - Ini mirip dengan pendekatan saya; Saya bertahun-tahun lebih cepat dari waktu saya! "Tata letak blok malas primitif untuk membangun gulir tak terbatas ke dalam aplikasi web." docs.google.com/document/d/…
Rudiger

@Rudiger Ya, saya pernah melihat ini di grup Blink sekitar sebulan yang lalu, tapi saya tidak begitu yakin bagaimana ini masuk ke dalam gambar. Layout malas beroperasi pada elemen yang benar-benar ada di DOM, yang sebenarnya tidak bisa kita lakukan. Tolong jelaskan :)
Tin

84

https://github.com/mleibman/SlickGrid/wiki

" SlickGrid menggunakan rendering virtual untuk memungkinkan Anda bekerja dengan mudah dengan ratusan ribu item tanpa penurunan kinerja. Bahkan, tidak ada perbedaan dalam kinerja antara bekerja dengan grid dengan 10 baris versus 100'000 baris. "

Beberapa hal penting:

  • Pengguliran virtual adaptif (menangani ratusan ribu baris)
  • Kecepatan rendering yang sangat cepat
  • Latar belakang pasca rendering untuk sel yang lebih kaya
  • Dapat dikonfigurasi & disesuaikan
  • Navigasi keyboard lengkap
  • Ubah ukuran kolom / atur ulang / tampilkan / sembunyikan
  • Kolom diotomatiskan & dipaksakan
  • Pemformat & editor sel Pluggable
  • Dukungan untuk mengedit dan membuat baris baru. "oleh mleibman

Ini gratis (lisensi MIT). Ini menggunakan jQuery.


Ini berfungsi dengan baik sampai tepat 131.001 baris ... Yaitu, ada satu baris kode seperti ini: data.length = Math.min(131000, parseInt(resp.total));... Dan, tentu saja, kode itu karena suatu alasan :(
Rudiger

6
Butuh sedikit kerja, tapi saya membuat beberapa perubahan untuk membuat grid tidak tergantung pada panjang dataarray. Ini adalah kludge, tetapi saya memiliki respons yang mengisi bigdataarray, dan datatarikan yang lebih kecil dari bigdataarray. Sisa program menggunakan larik data yang lebih kecil, kecuali untuk pengukuran bilah gulir dan beberapa tempat lain yang sekarang tidak terikat untuk sejumlah besar baris. Secara keseluruhan, jauh lebih mudah daripada menulis sendiri.
Rudiger

8
@Rudiger: SlickGrid sekarang mendukung jumlah baris yang tidak terbatas secara asli. Lihat github.com/mleibman/SlickGrid/tree/unlimited-rows . Setelah ini diuji secara menyeluruh itu akan digabungkan ke cabang utama.
Timah

Saya mencoba menggunakan slickgrid untuk menampilkan header excel, dan saya melihat bahwa ketika memiliki terlalu banyak kolom, slickgrid hanya mengoptimalkan pengguliran baris dan bukan kolom. Saya juga memperhatikan bahwa ketika memiliki lebih dari 120 kolom atau lebih - slickgrid menempatkan baris baru di baris baru. Bisakah jumlah baris maksimum ditetapkan di suatu tempat di file?
oneiros

jika Anda menginginkan sesuatu yang sangat cepat, jangan mengandalkan apa pun yang menggunakan jquery untuk melakukan hal-hal di inti, dan lebih baik menggunakan innerHTML daripada DOM append. Scrollbar Javascript bisa terlihat lebih lambat daripada scrollbar browser pada komputer lambat, hindari aturan css yang rumit, dan Anda harus menghabiskan waktu menyederhanakan tata letak satu baris. Optimalisasi mikro dapat menjadi signifikan dalam kasus ini. Ini hanyalah praktik umum untuk meningkatkan kinerja. jsPerf.com adalah teman Anda.
Vitim.us

37

Grid terbaik menurut saya adalah di bawah ini:

3 pilihan terbaik saya adalah jqGrid, jqxGrid dan DataTables. Mereka dapat bekerja dengan ribuan baris dan mendukung virtualisasi.


1
+1 untuk daftar, meskipun tidak banyak perbandingannya. Awal yang baik adalah menambahkan jumlah komit untuk masing-masing - 33 untuk Flexigrid seperti yang sekarang, vs 491 untuk SlickGrid.
Dan Dascalescu

12
Sekrup batas edit komentar 5 menit SO. # 1 - jqGrid - 1000+ commit ; # 2 - 752 untuk DataTables ; # 3 - 491 untuk SlickGrid ; # 4 - 33 berkomitmen untuk Flexigrid . Ingrid - tidak ada pembaruan sejak Juni 2011 . jqGridView - tidak ada pembaruan sejak 2009
Dan Dascalescu

3
Membangun pada komentar sebelumnya, saya termasuk jumlah garpu per proyek di sini: # 1 - SlickGrid - 670 garpu; # 2 - jqGrid - 358 garpu; # 3 - Flexigrid - 238; # 4 - DataTables - 216; # 5 - Ingrid - 41; # 6 - jqGridView - 0;
ljs.dev


Dapatkah saya berkomentar bahwa Slickgrid masih hidup dan sehat, tetapi mleibman yang dikutip di atas sudah mati. Tautan baru: github.com/6pac/SlickGrid (mleibman merujuknya dalam catatan akhir pada repo-nya), atau www.slickgrid.net
Ben McIntyre

25

Saya tidak bermaksud memulai perang api, tetapi dengan anggapan peneliti Anda adalah manusia, Anda tidak mengenal mereka sebaik yang Anda pikirkan. Hanya karena mereka memiliki petabyte data tidak membuat mereka mampu melihat jutaan catatan dengan cara apa pun yang berarti. Mereka mungkin mengatakan ingin melihat jutaan rekaman, tapi itu konyol. Mintalah para peneliti Anda yang paling cerdas melakukan beberapa matematika dasar: Asumsikan mereka menghabiskan 1 detik melihat setiap catatan. Pada tingkat itu, akan dibutuhkan 10.00000 detik, yang bekerja lebih dari enam minggu (40 jam kerja-minggu tanpa istirahat untuk makanan atau toilet).

Apakah mereka (atau Anda) serius berpikir satu orang (yang melihat grid) dapat mengumpulkan konsentrasi semacam itu? Apakah mereka benar-benar menyelesaikan banyak hal dalam 1 detik, atau apakah mereka (lebih mungkin) menyaring hal-hal yang tidak diinginkan? Saya menduga bahwa setelah melihat subset "berukuran cukup", mereka dapat mendeskripsikan filter untuk Anda yang akan secara otomatis menyaring catatan tersebut.

Seperti paxdiablo dan Sleeper Smith dan Lasse V Karlsen juga menyiratkan, Anda (dan mereka) belum memikirkan persyaratannya. Di sisi atas, sekarang Anda telah menemukan SlickGrid, saya yakin kebutuhan untuk filter-filter itu menjadi jelas.


2
Memiliki kebutuhan jutaan baris tidak selalu tentang melihatnya. Kadang-kadang klien menginginkan dump sebagian catatan untuk berjalan di sistem analisis data mereka sendiri.
cbmeeks

10
Jika ini adalah dump data untuk analisis mereka sendiri, maka itu tidak akan ditampilkan dalam kotak pada halaman web, bukan?
Steven Benitez

5
saya tidak harus melihat semuanya sekaligus. Itulah gunanya menyortir kolom dan Ctrl+Funtuk apa. Alternatif (paging, pencarian situs web) jauh lebih buruk. Lihat saja StackOverflow ketika mencoba menelusuri pertanyaan atau jawaban, Reddit untuk menggulir melalui riwayat komentar pengguna. Penyortiran dan pencarian instan memberikan kekuatan yang dimiliki Windows Explorer, tetapi kekurangan situs web.
Ian Boyd

15

Saya dapat mengatakan dengan kepastian yang cukup baik bahwa Anda serius tidak perlu menunjukkan jutaan baris data kepada pengguna.

Tidak ada pengguna di dunia yang akan dapat memahami atau mengelola kumpulan data itu sehingga bahkan jika Anda secara teknis berhasil melakukannya, Anda tidak akan memecahkan masalah yang diketahui untuk pengguna itu.

Sebagai gantinya saya akan fokus pada mengapa pengguna ingin melihat data. Pengguna tidak ingin melihat data hanya untuk melihat data, biasanya ada pertanyaan yang diajukan. Jika Anda berfokus untuk menjawab pertanyaan-pertanyaan itu, maka Anda akan lebih dekat dengan sesuatu yang memecahkan masalah aktual.


16
Pengguna saya adalah peneliti yang terbiasa dengan petabyte data. Saya rasa saya tahu pengguna saya sedikit lebih baik daripada Anda, meskipun Anda tentu benar dalam kasus umum. Adapun alasannya , datagrid ini hanyalah bagian dari seperangkat alat untuk mengelola data besar.
Rudiger

7

Saya merekomendasikan Ext JS Grid dengan fitur Buffered View.

http://www.extjs.com/deploy/dev/examples/grid/buffer.html


ExtJs, memang. Ini pada dasarnya dibangun khusus untuk presentasi data
KdgDev

1
ExtJs sangat bagus saya ingin menangis karena tidak dibangun di atas jQuery
James Westgate

Sekarang Anda hanya dapat memuat bagian terkait-jaringan dari ExtJS, sehingga menambahkan grid ExtJS ke aplikasi Anda tidak akan terlalu berat. Namun, Anda masih harus mempertimbangkan perbedaan dalam penampilan dan menggunakan cara bertema ExtJS hanya untuk komponen itu.
JD Smith

7

(Penafian: Saya adalah penulis w2ui)

Saya baru-baru ini menulis sebuah artikel tentang bagaimana menerapkan JavaScript grid dengan 1 juta catatan ( http://w2ui.com/web/blog/7/JavaScript-Grid-with-One-Million-Records ). Saya menemukan bahwa pada akhirnya ada 3 batasan yang mencegah dari mengambilnya lebih tinggi:

  1. Ketinggian div memiliki batas (dapat diatasi dengan scrolling virtual)
  2. Operasi seperti pengurutan dan pencarian mulai lambat setelah sekitar 1 juta rekaman
  3. RAM terbatas karena data disimpan dalam array JavaScript

Saya telah menguji grid dengan 1 juta catatan (kecuali IE) dan kinerjanya baik. Lihat artikel untuk demo dan contoh.


Dengan catatan satu juta ini halaman html Anda berukuran 3MB, tetapi ketika saya memuat data saya halamannya 15MB, apakah w2ui dapat mengatasinya? Saya membutuhkan semua data untuk beberapa perhitungan.
Chetan S. Choudhary

6

dojox.grid.DataGrid menawarkan abstraksi JS untuk data sehingga Anda dapat menghubungkannya ke berbagai backend dengan toko dojo.data yang disediakan atau menulis sendiri. Anda pasti membutuhkan satu yang mendukung akses acak untuk banyak catatan ini. DataGrid juga menyediakan aksesibilitas penuh.

Sunting jadi di sini adalah tautan ke artikel Matthew Russell yang seharusnya memberikan contoh yang Anda butuhkan, melihat jutaan catatan dengan dojox.grid. Perhatikan bahwa ia menggunakan versi grid yang lama, tetapi konsepnya sama, hanya ada beberapa peningkatan API yang tidak kompatibel.

Oh, dan ini open source sepenuhnya gratis.



4

Berikut adalah beberapa optimasi yang dapat Anda terapkan untuk mempercepat. Hanya berpikir keras.

Karena jumlah baris dapat mencapai jutaan, Anda perlu sistem caching hanya untuk data JSON dari server. Saya tidak bisa membayangkan ada orang yang ingin mengunduh semua X juta item, tetapi jika mereka melakukannya, itu akan menjadi masalah. Tes kecil ini di Chrome untuk array pada 20M + integer crash di mesin saya terus-menerus.

var data = [];
for(var i = 0; i < 20000000; i++) {
    data.push(i);
}
console.log(data.length);​

Anda bisa menggunakan LRU atau algoritma caching lainnya dan memiliki batas atas berapa banyak data yang ingin Anda cache.

Untuk sel tabel sendiri, saya pikir membangun / menghancurkan node DOM bisa mahal. Alih-alih, Anda bisa menentukan sebelumnya jumlah sel X, dan kapan pun pengguna menggulir ke posisi baru, masukkan data JSON ke dalam sel-sel ini. Bilah gulir hampir tidak memiliki hubungan langsung dengan berapa banyak ruang (tinggi) yang diperlukan untuk mewakili seluruh dataset. Anda bisa secara sewenang-wenang mengatur ketinggian penampung tabel, katakan 5000px, dan petakan itu ke jumlah baris. Misalnya, jika ketinggian wadah adalah 5000px dan ada total baris 10M, maka di starting row ≈ (scroll.top/5000) * 10Mmana scroll.topmewakili jarak gulir dari bagian atas wadah. Demo kecil di sini .

Untuk mendeteksi kapan meminta lebih banyak data, idealnya sebuah objek harus bertindak sebagai mediator yang mendengarkan gulir peristiwa. Objek ini melacak seberapa cepat pengguna menggulir, dan ketika sepertinya pengguna melambat atau benar-benar berhenti, membuat permintaan data untuk baris yang sesuai. Mengambil data dengan cara ini berarti data Anda akan terfragmentasi, jadi cache harus dirancang dengan mempertimbangkan hal itu.

Juga batas browser pada koneksi keluar maksimum dapat memainkan bagian penting. Seorang pengguna dapat menggulir ke posisi tertentu yang akan memecat permintaan AJAX, tetapi sebelum itu selesai pengguna dapat menggulir ke bagian lain. Jika server tidak cukup responsif permintaan akan antri dan aplikasi akan terlihat tidak responsif. Anda bisa menggunakan manajer permintaan melalui mana semua permintaan dialihkan, dan itu dapat membatalkan permintaan yang tertunda untuk membuat ruang.


4

Saya tahu ini pertanyaan lama tapi tetap saja .. Ada juga dhtmlxGrid yang dapat menangani jutaan baris. Ada demo dengan 50.000 baris tetapi jumlah baris yang dapat dimuat / diproses dalam grid tidak terbatas.

Penafian: Saya dari tim DHTMLX.


Saya ingin menampilkan 10 MB data Json dan ingin menggunakannya dalam perhitungan, dapatkah DHTMLX melakukan hal itu, Dengan data dan tag html itu, halaman browser saya sekitar 15 MB. Apakah layak menggunakan DHTMLX?
Chetan S. Choudhary


3

Penafian: Saya banyak menggunakan YUI DataTable tanpa sakit kepala untuk waktu yang lama . Ia kuat dan stabil. Untuk kebutuhan Anda, Anda dapat menggunakan suport ScrollingDataTable yang

  • gulir x
  • menggulir-y
  • xy-scrolling
  • Mekanisme Acara yang kuat

Untuk apa yang Anda butuhkan, saya pikir Anda inginkan adalah tableScrollEvent . API-nya mengatakan

Dipecat ketika gulir tetap DataTable memiliki gulir.

Karena setiap DataTable menggunakan DataSource, Anda dapat memantau datanya melalui tableScrollEvent bersama dengan ukuran render loop untuk mengisi ScrollingDataTable Anda sesuai dengan kebutuhan Anda.

Render ukuran lingkaran kata

Dalam kasus di mana DataTable Anda perlu menampilkan keseluruhan set data yang sangat besar, konfigurasi renderLoopSize dapat membantu mengelola rendering DOM browser sehingga utas UI tidak terkunci pada tabel yang sangat besar . Nilai apa pun yang lebih besar dari 0 akan menyebabkan rendering DOM dieksekusi di rantai setTimeout () yang merender jumlah baris yang ditentukan di setiap loop. Nilai ideal harus ditentukan per implementasi karena tidak ada aturan keras dan cepat, hanya pedoman umum:

  • Secara default renderLoopSize adalah 0, jadi semua baris dirender dalam satu loop. A renderLoopSize> 0 menambahkan overhead jadi gunakan dengan bijaksana.
  • Jika kumpulan data Anda cukup besar (jumlah baris X jumlah kompleksitas pemformatan Kolom X) yang dialami pengguna dalam latensi rendering visual dan / atau menyebabkan skrip digantung, pertimbangkan untuk mengatur renderLoopSize .
  • RenderLoopSize di bawah 50 mungkin tidak sepadan. RenderLoopSize> 100 mungkin lebih baik.
  • Satu set data mungkin tidak dianggap cukup besar kecuali memiliki ratusan dan ratusan baris.
  • Memiliki renderLoopSize> 0 dan <total rows memang menyebabkan tabel di-render dalam satu loop (sama seperti renderLoopSize = 0) tetapi juga memicu fungsionalitas seperti striping post-render yang akan ditangani dari thread setTimeout yang terpisah.

Misalnya

// Render 100 rows per loop
 var dt = new YAHOO.widget.DataTable(<WHICH_DIV_WILL_STORE_YOUR_DATATABLE>, <HOW YOUR_TABLE_IS STRUCTURED>, <WHERE_DOES_THE_DATA_COME_FROM>, {
     renderLoopSize:100
 });

<WHERE_DOES_THE_DATA_COME_FROM> hanya satu DataSource . Ini bisa berupa JSON, JSFunction, XML dan bahkan elemen HTML tunggal

Di sini Anda dapat melihat tutorial Sederhana, yang disediakan oleh saya. Ketahuilah tidak ada pluglin DATA_TABLE lainnya yang mendukung klik tunggal dan ganda pada saat yang sama. YUI DataTable memungkinkan Anda. Dan banyak lagi, Anda dapat menggunakannya bahkan dengan JQuery tanpa sakit kepala

Beberapa contoh, bisa Anda lihat

Jangan ragu untuk bertanya tentang hal lain yang Anda inginkan tentang YUI DataTable.

salam,


3

Saya agak gagal melihat intinya, untuk jqGrid Anda dapat menggunakan fungsi gulir virtual:

http://www.trirand.net/aspnetmvc/grid/performancevirtualscrolling

tetapi sekali lagi, jutaan baris dengan penyaringan dapat dilakukan:

http://www.trirand.net/aspnetmvc/grid/performancelinq

Saya benar-benar gagal melihat titik "seolah-olah tidak ada halaman" meskipun, maksud saya ... tidak ada cara untuk menampilkan 1.000.000 baris sekaligus di browser - ini adalah 10MB HTML mentah, saya agak gagal melihat mengapa pengguna tidak ingin melihat halaman.

Bagaimanapun...


2

Pendekatan terbaik yang bisa saya pikirkan adalah dengan memuat potongan data dalam format json untuk setiap gulir atau batas tertentu sebelum gulir berakhir. json dapat dengan mudah dikonversi menjadi objek dan karenanya baris tabel dapat dibangun dengan mudah tanpa mengganggu


Begitulah cara saya memilikinya. Permintaan dibuat untuk satu set baris yang dikirim kembali di JSON ... Saya mencari renderer sisi klien javascript yang mendukung ini!
Rudiger

Apa??? Apa itu "renderer situs klien"? Setiap javascript masih perlu melakukan panggilan ajax - jadi Anda masih harus menyelesaikan beberapa format transportasi. Anda tidak dapat melarikan diri dari pekerjaan. Tidak ada yang akan melakukan ini untuk Anda teman saya.
Andriy Drozdyuk

1
Saya tahu bahwa panggilan AJAX harus dilakukan; bagian ini sederhana. Klien meminta sesuatu seperti "mulai = 20 & batas = 20" dan mengambil baris 20-39 dari server (format XML atau JSON). "Renderer sisi klien" (terminologi saya!) Membuat permintaan ini secara cerdas (mis. Ketika pengguna menggulir ke bawah), dan merender hasilnya secara mulus di kotak yang cantik. Bertentangan dengan apa yang Anda katakan, orang lain telah melakukan pekerjaan ini untuk saya. Itulah semua jawaban lain untuk pertanyaan ini.
Rudiger

Sepertinya tidak ada orang lain yang melakukannya untuk Anda :)
Andriy Drozdyuk

1

Saya sangat merekomendasikan Open rico . Sulit untuk diterapkan di awal, tetapi begitu Anda meraihnya, Anda tidak akan pernah melihat ke belakang.




0

Lihatlah dGrid:

https://dgrid.io/

Saya setuju bahwa pengguna tidak akan pernah, pernah perlu melihat jutaan baris data sekaligus, tetapi dGrid dapat menampilkannya dengan cepat (satu layar penuh pada suatu waktu).

Jangan merebus lautan untuk membuat secangkir teh.


secangkir teh Anda (tautan) tidak ditemukan. :)
Akshay

Ia memiliki situsnya sendiri sekarang :)
ColemanTO
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.