從一個開源專案到龐大的開源矩陣，他是怎麼做到的？

大家好，我卡頌。

很多開源作者都經歷過如下過程：

• 有個好的開源點子

• 擼起袖子加油幹

• 開源專案獲得社群認可， star數量就是自己的動力

• 隨著維護時間變長，遇到挫折（時間上的消耗、伸手黨的不理解...）

• 心灰意冷，逐漸停止維護

今天要介紹的主人公 「Tanner Linsley」是 React Table與 React Query的作者。

Tanner Linsley

不同於其他開源作者在激情散去後專案逐漸荒廢， 「Tanner Linsley」不僅持續迭代專案，而且隨著維護的專案越來越多，甚至形成了專案矩陣。

上面提到的 React Table、 React Query，再加上其他四個專案已經合併到 TanStack專案下，形成了統一的品牌（ TanStack）：

他是如何做到的？本文來聊聊 「Tanner Linsley」的開源之路。

開源的收益

談到 「開源」，大家會想到很多標籤 ——  「免費」、 「用愛發電」、 「貢獻」......

但事實上，任何工作如果沒有穩定的物質收益（對，說的就是錢），都是很難持續的。

傳統意義上，開源作者主要依靠 「贊助」（比如 Github Sponsor ^[1]）。

相比開源的工作量， 「贊助」通常是杯水車薪。所以開源作者很難擴大自己維護專案的規模。

「Tanner」在 Github Sponsor ^[2]已經擁有180個贊助者，算很不錯的了。

Tanner的贊助者

但從 「擴大維護專案的規模」角度看，還遠遠不夠。

那麼是什麼使得 「Tanner」有穩定的收益，從而維護更多專案呢？

答案是：課程。

TanStack矩陣中的 TanStack Query（即 React Query）的 官方課程 ^[3]已經售出8w份了，按當前的折扣價156刀算，這部分收入有稅前1200w刀了。

雖然實際收入肯定達不到這個數，但數百萬刀的收益還是有的。

所以，只要持續產出優秀的開源專案，就能獲得穩定的課程收益，形成正反饋。

那麼，一個優秀的開源專案是如何誕生的呢？接下來我們聊聊 React Table的發展史。

React Table發展史

在2015年時， 「Tanner」是一家創業公司 nozzle的聯合創始人。

nozzle的主營業務是：反向爬取 Google搜尋結果頁的資料，將這些資料整合分析後，提供給有 SEO需要的廣告主。

這就需要做很多資料視覺化相關工作。

當時 nozzle的技術棧是 Angular，使用 ag-grid實現表格。

為了專案的後續發展， 「Tanner」決定將專案整體遷移到 React技術棧。

但當時 React技術棧沒有優秀的表格元件，於是他決定自己實現一個。

自用與開源的衝突

React Table的最初版完全是為了滿足自用，開源只是順手的事兒。

作為一個開源元件， React Table最初的使用方式如下：

<
ReactTable

  
data=
{data}

  
columns=
{columns}

/>

與 「自用元件」不同， 「開源元件」需要滿足儘可能多人的需求。

於是，隨著 React Table的 star越來越多， issues也接踵而至。

比如：

• 能夠實現分頁功能麼？

• 我能給 Header元件傳自定義 props麼？

• 我能用 CSS-In-JS麼？

這些定製化需求讓 「Tanner」疲於奔命，也導致 React Table越來越臃腫。

最終， React Table有了137個 props配置項來應對這些定製化需求：

接下來該如何維護，難道任由 React Table的配置項不斷膨脹麼？

還好， 「Tanner」找到了解決方案，那就是 render props。改版後的寫法如下：

ReactTable元件只負責表格的核心邏輯，內部的邏輯交給 render props實現。

想要自定義表頭？自己去實現。

想要分頁？自己去實現。

當 render props版本的 React Table就快實現時， React核心團隊釋出了 Hooks。

於是， React Table重新開發了基於 Hooks的版本：

乍看之下，相比於 render props的版本， Hooks的版本只是將 ReactTable元件變為 useTable方法。

但實際上，這是個巨大的飛躍。

因為，格局一下開啟了。

格局開啟

render props可以認為是 React的一個特性，他是與 React相關的。

而 Hooks本身僅僅是帶有特殊功能的函式，這意味著他可以脫離 React單獨存在。

得益於 React Hooks的思想被社群廣泛接受，越來越多框架都實現了自己的 Hooks（比如 Vue3中的 Composition API）。

所以，新版 React Table被設計為 「框架不可知」（Framework Agnostic）。

簡單來說，由 @tanstack/table-core再加不同框架的 adapter就能實現針對不同框架的 table元件：

比如，針對 Solid.js，只需要適配他的 「細粒度更新」與 context，就能實現 Solid Table：

這種 「框架不可知」的開源元件擴大了元件的受眾範圍，也降低了開發者遷移技術棧後的上手成本。

後記

開源不是打打殺殺，而是人情世故。

按理說， AG Grid應該是 Tanstack Table的直接競爭對手。但是，基於 「合作共贏」的態度，兩者形成夥伴關係，共同致力於：

• 教育前端開發者這兩個庫之間的差異以及如何選擇

• 當一個庫不符合需求時，推薦對方。以求兩者共同覆蓋儘可能多的應用場景

AG Grid團隊甚至是 Tanstack的大讚助商：

這種 「合作共贏，一起把蛋糕做大」（或者說 「寡頭壟斷」）的開源模式，值得廣大開源作者借鑑。

你有沒有用過 React Table或 React Query呢？對於他們發展至今取得的成績與收益，你怎麼看？

參考資料