大家好，我卡颂。

很多开源作者都经验过如下过程：

  • 有个好的开源点子
  • 撸起袖子加油干
  • 开源我的项目取得社区认可，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呢？对于他们倒退至今获得的问题与收益，你怎么看？