共计 2225 个字符，预计需要花费 6 分钟才能阅读完成。
大家好，我卡颂。
很多开源作者都经验过如下过程：
- 有个好的开源点子
- 撸起袖子加油干
- 开源我的项目取得社区认可，
star数量就是本人的能源 - 随着保护工夫变长，遇到挫折（工夫上的耗费、伸手党的不了解 …）
- 心灰意冷，逐步进行保护
明天要介绍的主人公 Tanner Linsley 是React Table与 React Query 的作者。
不同于其余开源作者在激情散去后我的项目逐步旷废，Tanner Linsley不仅继续迭代我的项目，而且随着保护的我的项目越来越多，甚至造成了我的项目矩阵。
下面提到的 React Table、React Query，再加上其余四个我的项目曾经合并到TanStack 我的项目下，造成了对立的品牌（TanStack）：
他是如何做到的？本文来聊聊 Tanner Linsley 的开源之路。
欢送退出人类高质量前端框架群，带飞
开源的收益
谈到 开源 ，大家会想到很多标签 —— 收费 、 用爱发电 、 奉献……
但事实上，任何工作如果没有稳固的物质收益（对，说的就是钱），都是很难继续的。
传统意义上，开源作者次要依附 资助（比方 Github Sponsor）。
相比开源的工作量，资助 通常是无济于事。所以开源作者很难扩充本人保护我的项目的规模。
Tanner在 Github Sponsor 曾经领有 180 个赞助者，算很不错的了。
但从 扩充保护我的项目的规模 角度看，还远远不够。
那么是什么使得 Tanner 有稳固的收益，从而保护更多我的项目呢？
答案是：课程。
TanStack矩阵中的 TanStack Query（即React Query）的官网课程
曾经售出 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呢？对于他们倒退至今获得的问题与收益，你怎么看？
