バーチャルスクロールの限界を突破する

はじめに 私は今、CSVエディタ SmoothCSV 3 を開発しています。フレームワークとして Tauri を採用しており、レンダラーにはWebの技術（React + TypeScript）を使っています。 CSVエディタは大量の行・セルを表示する必要がありますが、Webの技術ではこのようなシーンではバーチャルスクロールを使うのが定石です。 SmoothCSVでもバーチャルスクロールを使っていましたが、どうやらこのバーチャルスクロールにも限界があるらしく、数百万行のような極端に大量のデータを表示する場合に最後まで表示しきれない問題に遭いました。 ここではバーチャルスクロールの基本と、その限界をどう乗り越えたかを紹介します。 About Me 株式会社ヘンリーでソフトウェアエンジニア & アーキテクト的なことをしつつ、個人開発してます。 Social accounts: kohii on

[Fushihara]

仮想dom自体の問題だけど、Ctrl+Aでの全選択が機能しなかったり、これみたいにスクロールを自作するとpageUpDownでのスクロールも全部js側で作り直さないといけなかったりするからキライ！

[atsushieno]

エディタとして何行まで耐えられるかのテストで割と満足できない段階で引っかかったということだろうから、UI設計として悪手かは関係なさそう / こういうのはA11y対応とかできる体力のある組織でやって／使ってほしい

[hwalker]

SmoothCSVちょうべんり！いつもありがとう！

[secseek]

この辺まで来るとGUIアプリケーションをレンダリングエンジンに処理させること自体に無理があるって感じがしてきますね

[Tack2Me]

そんなに大量の選択肢からスクロールさせるUIがそもそも悪手な気がするが

[sasashin]

「ブラウザが提供している標準UIを作り直すべきでない」みたいなことがコメ欄に書かれてるけど、WebページじゃなくてGUIアプリに仕立てるんだから好きにすればええやろとしか…。

[akymrk]

“ブラウザで表示できる要素の幅や高さには上限があります”"Safari: 33,554,428px Chromium: 16,777,216px""一般的にスクロールバーのレールを Track、つまみを Thumb と呼びます。"https://github.com/kohii/smoothcsv3

[yarumato]

“数百万行のような極端に大量のデータを表示する場合に最後まで表示しきれないバーチャルスクロール（見えているアイテムだけをJavaScriptで動的に生成する）の限界問題。スクロールの仕組みを自作、Reactで実装”

[peperon_brain]

GitHubのProjectsのテーブルビューとかcommitのdiffとかもおそらく似た実装。んでvisibleな範囲しかCtrl+Fが効かない。

[umai_bow]

Spreadsheetとかドアしてるんだ

[north_korea]

位置計算をちゃんとやる必要のある特殊なスクロール要素をHTMLとJSで作ると、高速で動かした時とかに不安定でズレたりするのでスマホアプリでネイティブ開発したくなる

[mushus]

高さに限界があるのでスクロールバーを自作して回避かー。 HTML自身にスクロールバー要素追加して欲しい感ある。