I went through the documentation and feature list of React DataGrid, and I wrote React DataGrid: A Free, Open-Source React Data Grid with an Enterprise Edition (An AG Grid Alternative)

現在我想用它的方式，像在真實專案中使用任何其他資料格那樣來試試看：從真實資料集開始，圍繞它建立實用互動，拿大量記錄來考驗這個表格，看看會在哪裡變得困難。

所以我做了一個 Space Mission & Satellite Explorer，這是一個小型、偏飛行動力學風格的網頁應用程式，用來探索不同機構、目的地、任務類型與年代中的任務。

這個專案使用一個 10 萬筆任務的即時資料庫，而一個 1,200 列的前端工作集 則支撐互動式分析體驗。這讓我有很好的機會測試的不只是基本的排序與分頁，還包括篩選、分面搜尋、分組、樞紐分析、列釘選、自訂儲存格渲染、虛擬捲動，以及伺服器端無限捲動。

我也基於同一份資料另外做了應用程式的兩個部分：一個用來彙總與視覺化資料集的 Mission Analytics 頁面，以及一個使用 Tree Data 來呈現單一任務時間軸的 Mission Details 頁面。

這篇文章會講我在打造它時發生了什麼，從設定 React DataGrid、配置第一批欄位，一直到處理 10 萬筆記錄，以及我是否會在下一個資料密集型的 React 專案中再次選用它。

TL;DR

我用 React DataGrid 做了一個 Space Mission Explorer，看看它在真實應用中的表現。

這個專案使用一個 1,200 列的前端資料集 進行互動式分析，以及一個透過伺服器端無限捲動載入的 10 萬列即時資料庫。

過程中我使用了以下功能：

• 多欄排序
• 快速搜尋
• 分面篩選
• 列分組
• 列釘選
• 樞紐表建立器
• 自訂儲存格渲染器
• 虛擬捲動
• CSV／Excel 匯出
• 用於任務時間軸的 Tree Data

整合過程比我預期中順利。API 從一開始就讓人覺得熟悉；我需要的大多數功能都能照著文件範例正常運作，只要做少量調整即可，而且在小型工作集與完整資料庫之間切換時也保持流暢。

當然，還是有幾個地方需要多花一些時間摸索，我後面會提到，不過整體來說，這次專案讓我對 React DataGrid 的印象，比只看功能列表時好得多。

我做了什麼：Space Mission Explorer

我把這個專案命名為 Orbital Index / Mission Data Terminal。

概念很簡單：把一大批虛構的太空任務記錄，轉化成開發者可以想像實際使用的東西，也就是一個可搜尋、可篩選的介面，讓你能依照機構、目的地、狀態、任務類型、發射日期、持續時間、成本與年代來探索任務。

我刻意沒有再做一個普通的 CRUD 後台，因為這份資料集本身就自然會產生資料格真正有用的那些問題。

一筆任務記錄有足夠多的結構化欄位，讓篩選與排序變得有意義。任務可以依機構或目的地分組。成本與持續時間可以彙總。而且任務本身也有自然的階層結構：

發射 → 地球軌道 → 轉月注入 → 月球軌道 → 下降與登陸 → 地表作業 → 返回地球

最後這一點也給了我測試 Tree Data 的理由，而不是只是為了多勾選一個功能而加入它。

最後這個應用程式有三個主要頁面：

• Mission Explorer： 主要的資料格介面，用於搜尋、篩選、分組、樞紐分析、編輯與探索任務資料庫。
• Mission Analytics： 一個以圖表為主的視圖，把同一份任務資料轉成成功率、機構比較、目的地分布、持續時間統計與成本分析。
• Mission Details： 單一任務視圖，包含中繼資料、機組與設備資訊、相關檔案，以及層級式任務時間軸。

Explorer 是我測試 React DataGrid 最多的地方。Analytics 頁面使用相同的 1,200 列工作集與彙總邏輯來產生視覺化結果，而 Details 頁面則替我提供了完全不同的使用情境來測試這個格狀元件的階層資料能力。

技術堆疊方面，我使用了 React、TypeScript、Tailwind CSS、React DataGrid、任務資料集，以及一個用於分析視圖的圖表函式庫。

在深入介紹這個資料格之前，先說一個透明說明：我用 vibe coding 做了初始專案設定中的一小部分，避免把太多時間花在其實不是這次實驗重點的樣板程式上。

這裡的目標不是證明我能從零打造整個太空任務網站；而是把時間花在真正使用 React DataGrid 上，看看它如何處理資料、互動與規模。

我刻意把專案維持在一個足以從頭到尾理解，但又複雜到一般 <table> 會開始出問題的規模。

你可以直接查看完整專案，自己探索這些任務。

https://orbitalindex.vercel.app/ Live Demo 👀

https://github.com/Hadil-Ben-Abdallah/space-mission-explorer GitHub Repository ⭐

設定 React DataGrid

在我完成專案結構之後，我想先把資料格跑起來，再去花時間做其他介面。我先從開源套件開始，並刻意讓第一版渲染保持簡單。

安裝很直接：

npm install react-open-source-grid

接著我引入了函式庫的樣式表：

import 'react-open-source-grid/dist/lib/index.css';

第一次測試時，我建立了一個只包含少數幾個任務欄位的小型資料格：

const columns: Column[] = [
  { field: 'mission', headerName: 'Mission', width: 200 },
  { field: 'agency', headerName: 'Agency', width: 120 },
  { field: 'status', headerName: 'Status', width: 140 },
  { field: 'launchDate', headerName: 'Launch Date', width: 130 },
  { field: 'destination', headerName: 'Destination', width: 150 },
];

之後，我為 Mission、Agency、Status、Launch Date、Destination、Mission Type 和 Duration 定義了有型別的欄位，並將資料集對應到這些欄位上。

在這個階段，API 讓我覺得很熟悉，所以我不需要花太多時間去學一個完全陌生的資料格模型。

另外，在開發過程中，我也一直把 React DataGrid 的 GitHub repository 和 documentation 放在旁邊參考，因為這是一次實作性的測試。

建立 Mission Explorer

我不想只做一個有幾列資料的資料格，然後說自己用過了。我想要有足夠多的資料與互動，來看看這個元件是否能處理真實應用中會遇到的複雜度。

最後我使用了兩種資料模式：一個 1,200 列的前端工作集 用於互動分析與虛擬捲動，以及一個透過伺服器端無限捲動按需載入記錄的 10 萬列即時資料庫。

這兩種模式的差異很有用，因為它讓我可以用兩種不同方式處理同一份任務資料，而不是為了效能測試硬生生造出一個巨大資料集。

<figcaption>Mission Explorer 頁面</figcaption> 

排序、篩選與搜尋

我先從任何資料格都該有的互動開始。欄位標題支援排序，包括多欄排序，所以我可以直接把任務先依機構排序，再依發射日期排序，而不需要自己寫自訂排序邏輯。

在篩選方面，我同時有全域搜尋列與各欄位的欄位篩選器。全域搜尋可以快速找到某個任務、機構或目的地，而欄位標題下方的篩選器則讓我在需要縮小特定欄位範圍時有更高的控制力。

側邊欄篩選器對這份資料集來說甚至更有用。它不是逼我把所有內容都打進搜尋框，而是讓 分面搜尋 面板能依 Agency、Status、Destination、Mission Type 與 Decade 進行篩選。每個分面也會顯示即時數量，例如 NASA (265) 或 Successful (839)，因此我可以立刻看出每個篩選條件代表多少資料。

如果我只想看 1990 年代、前往火星、且成功的 NASA 任務，我可以從好幾個維度同時縮小資料集，而不用自己另外做一套複雜的篩選介面。

我也測試了欄位調整大小與重新排序，兩者在我把 Explorer 調整成不同螢幕尺寸與工作流程時都很容易使用。

<figcaption>排序、篩選與搜尋</figcaption> 

分組與釘選

當篩選功能運作後，我想看看這個資料格如何處理更偏分析性的互動。

React DataGrid 讓我可以把欄位拖曳到表格上方的分組區。這表示我可以依像是「Agency」這樣的欄位來分組任務，然後再用另一個欄位進一步組織，而不是把每個任務都當成孤立的一列。

<figcaption>分組與釘選</figcaption> 

我也把四個參考任務釘選在資料格最上方。這是個小功能，但我在處理大型資料集時覺得非常實用，因為重要記錄在我捲動整個資料庫時仍然保持可見。

樞紐表

Explorer 最有趣的部分是內建的 樞紐表 建立器。

我不需要為每個想做的分析手動寫彙總邏輯，只要選擇 Row Group By、Pivot Column、Value Column 與 Aggregation，然後直接從介面套用設定即可。我也可以切換總計列與總計欄。

舉例來說，我可以依機構分組任務，再按目的地做樞紐，並彙總持續時間或成本等數值。這讓資料格從單純瀏覽記錄的地方，變成我可以用來探索資料集的工具。

<figcaption>樞紐表</figcaption> 

自訂儲存格、總計與匯出

我也使用自訂儲存格渲染，讓資料格更容易掃讀。任務狀態不再只是純文字，而是以有顏色區分的徽章來表示 Successful、Planned、Partial Success、Failed、Cancelled 與 in progress。工作集也包含一個總計頁尾，可彙總持續時間與成本等數值。

在資料格周圍，我加入了我在正式資料表中實際會想用到的控制項：欄位挑選器、CSV 與 Excel 匯出、版面重設控制項，以及四種密度選項，從 Ultra Compact 到 Comfortable。

<figcaption>自訂儲存格與總計</figcaption> 

<figcaption>CSV 與 Excel 匯出</figcaption> 

我最喜歡的是，我可以把分面篩選、分組、樞紐、釘選列、自訂渲染器與匯出整合在同一個介面裡，而頁面不會變成一堆彼此分離的控制元件集合。

建立 Mission Analytics

當 Mission Explorer 完成後，我想用同一份資料來做一些不只是瀏覽單筆記錄的事情，所以我做了第二個頁面，Mission Analytics。

這個頁面刻意採用圖表優先的設計。它不是再顯示另一個表格，而是使用與 Explorer 相同的任務資料與彙總邏輯，建立一組視覺化結果，回答關於任務歷史、機構、目的地與成本的更高層次問題。

在最上方，我加了四張摘要卡片：

• 1,200 筆涵蓋任務
• 79.6% 平均成功率
• 6691.2 億美元 計畫成本
• 1,543 天 平均任務持續時間

在這些卡片下方，頁面包含五種不同的視覺化：按年代的發射節奏、機構可靠度、目的地分布、按任務類型的成功狀況，以及成本對任務持續時間。

<figcaption>Mission Analytics 頁面</figcaption> 

發射節奏與機構可靠度

第一張圖表是 Launch Cadence by Decade，顯示資料集中不同年代的任務數量與成功任務數量如何變化。

這讓資料庫多了一個在 Explorer 裡看單列時不明顯的歷史維度。與其問哪些任務發射了，我開始可以問任務活動如何隨時間變化。

接著，Agency Reliability 圖表比較各機構，例如 NASA、SpaceX、Roscosmos、ESA、CNSA、ISRO、JAXA 與 Blue Origin 的發射量與平均成功率。

這裡就是彙總能力變得很有用的地方。這張圖表不是另外為儀表板獨立建立一份資料集，而是直接由我已經在 Explorer 中進行篩選、分組與分析的同一份任務記錄衍生出來。

<figcaption>發射節奏與機構可靠度</figcaption> 

目的地、任務類型與成本

另外三個視覺化則從同一份資料的不同維度切入。

Destination Distribution 圖表顯示資料庫中的任務都前往哪些地方，目的地包括 Earth Orbit、Moon、Mars、Asteroid Belt、Deep Space 與 Jupiter。

Success Profile by Mission Type 則從另一個角度比較不同任務類型的成功率，例如 rovers、orbiters、flybys、robotic landers、space telescopes 與 sample-return missions。

最後，Cost vs. Mission Duration 散佈圖讓我可以觀察昂貴的任務是否也往往持續更久。每個點代表一個單獨任務，能更容易找出特別昂貴或特別長期運作的計畫。

我覺得有趣的是，這一頁其實不需要再放另一個資料格，React DataGrid 依然能發揮作用。這個資料格背後的資料集與彙總邏輯仍然在運作；我只是把結果用更容易視覺解讀的方式呈現出來。

<figcaption>目的地、任務類型與成本</figcaption>

建立 Mission Details 頁面

在處理完整資料庫之後，我希望第三個頁面做相反的事：把我從 10 萬筆任務縮小到某一個特定任務。

這次我選用的是 MX-000006, Apollo VIII。這個頁面把任務的主要資訊整合在一起，包括發射日期、持續時間、計畫成本與機組人員，而且不需要把所有內容再塞進另一個大型表格裡。

<figcaption>Mission Details 頁面</figcaption> 

不過，這個頁面最有趣的部分是 Mission Timeline。

使用 Tree Data 呈現真實任務時間軸

任務不只是一些彼此無關欄位的集合。它天然就有順序結構：發射發生在軌道進入之前，而軌道進入又發生在主要任務作業之前，以此類推。

這讓時間軸成為使用 Tree Data 的好地方。

以 Apollo VIII 為例，我把任務分成 5 個階段：

Apollo VIII
├── Launch
├── Orbit Insertion
├── Payload Commissioning
├── Operations
└── Deorbit

每個階段都有自己的 COMPLETE 狀態徽章與 T+ 天數偏移，因此這個時間軸同時提供了階層關係與任務的時間脈絡。

<figcaption>真實任務時間軸的 Tree Data</figcaption> 

這也是那種在我真的有一個應用程式要做之後，才更有意義的功能。我本來可以為這個時間軸做一個自訂的巢狀元件，但 Tree Data 本來就很自然地對應這種結構化資訊。

這個頁面的其餘部分包含 Crew Manifest、Payload & Equipment 與 Related Dossiers 區塊。這些內容讓額外的任務資訊保持可存取，但又不會把頁面變成另一個過於密集的資料管理畫面。

<figcaption>Crew Manifest、Payload & Equipment 與 Related Dossiers</figcaption> 

到這個階段，我讓應用程式的三個部分都能一起運作：

• Mission Explorer：用來搜尋與操作資料庫
• Mission Analytics：用來從更高層次理解資料
• Mission Details：用來深入查看單一任務

這讓我有一個比小型 demo 表格更適合評估 React DataGrid 的環境。我在同一個專案裡，同時測試了真實的篩選、分組、樞紐分析、階層資料、自訂渲染與大型資料集。

主題與 UI 客製化

功能完成後，我花了一些時間讓這個資料格真正融入應用程式。預設的資料格外觀其實也能用，但它不太符合我想要的那種深色、青綠色點綴的 飛行動力學終端機 風格。

我使用主題變數來調整資料格外觀，並為任務狀態徽章加入自訂儲存格渲染。這些徽章針對 Successful、Planned、Partial Success、Failed、Cancelled 與 in progress 等狀態使用不同顏色，讓掃視 Explorer 更容易。

我也使用了四種密度模式，Ultra Compact、Compact、Normal 與 Comfortable，所以每列顯示的資訊量可以在不重建資料格版面的情況下調整。

我很喜歡這一點：客製化不需要我去跟元件的預設樣式硬碰硬。大多數工作其實是在讓 React DataGrid 符合專案的視覺語言，而不是設法繞開這個資料格本身。

開發者體驗：哪些容易，哪些比較費工

整體開發者體驗是這個專案裡最正面的部分之一。安裝與把第一個可用的資料格顯示出來，比我預期花的時間更少，而且 API 讓人覺得很熟悉。

當基本資料格開始運作後，加入排序、篩選、分組與樞紐表建立器都很直接，而且和文件範例一致。Mission Details 頁面的 Tree Data 實作也是如此。我不需要一直想辦法讓函式庫做它本來就不是設計來做的事。

我在操作資料格時也特別注意無障礙性。我還測試了鍵盤導覽，並在使用介面時留意資料格的 ARIA 行為。文件也提供了足夠的範例，讓我能理解我正在使用的那些較少見功能。

不過，並不是所有部分都同樣容易。越專門的功能，需要理解的時間就比日常操作，例如排序或篩選，來得多。樞紐表建立器與 Tree Data 設定是我花最多時間對照範例、確認資料結構的地方。

React DataGrid 對比基本 HTML 表格：我會怎麼選

如果我只是要顯示五到十列靜態資料，我不會選 React DataGrid。基本的 HTML 表格或輕量級 React 表格會更簡單，也足以勝任。

但這個專案的情況完全不同。

當我需要 10 萬筆任務、分面搜尋、多欄排序、分組、樞紐分析、Tree Data、自訂儲存格渲染，以及伺服器端無限捲動時，基本表格就得由我自己實作其中很大一部分功能。

這就是 React DataGrid 更合理的地方。與其花時間建立與維護表格基礎設施，不如把精力放在真正的應用程式：任務應該如何組織、使用者應該能探索什麼、以及分析功能應該如何運作。

React DataGrid 值不值得用？

在實作了一個專案之後，我認為 React DataGrid 很適合那些資料本身就是使用者體驗重要部分的應用程式。

我特別會考慮用在以下情境：

• 資料密集型儀表板
• 分析型應用程式
• 後台管理介面
• 金融應用程式
• 內部商業工具
• 使用大型資料集的應用程式
• 具有複雜篩選或分組需求的專案
• 具有階層資料的應用程式
• 需要伺服器端資料載入的 React 應用程式

Space Mission Explorer 是很好的測試案例，因為它一次結合了好幾項需求。我有一個 1,200 列的前端工作集用於互動分析，也有一個透過伺服器端無限捲動載入的 10 萬筆任務即時資料庫。

最後想法

打造 Space Mission Explorer 讓我對 React DataGrid 的理解，比只看功能清單更完整。

我能把一份真實資料集做成一個可互動的 10 萬列任務資料庫探索器，圍繞它建立分析頁面，並用 Tree Data 做任務時間軸，而不需要自己搭建資料格基礎設施。

對資料密集型的 React 應用程式來說，這才是最重要的：

<mark>資料格應該替你承擔資料的複雜度，讓你能專注於建立圍繞它的產品。</mark>

感謝閱讀！🙏🏻 <br/> 希望這對你有幫助 ✅ <br/> 歡迎按讚與追蹤，獲得更多內容 😍 <br/> 由 Hadil Ben Abdallah 以 💙 製作

https://dev.to/hadil

原文出處：https://dev.to/hadil/i-used-react-datagrid-to-build-a-real-space-mission-explorer-4g8b