如果你的前端已经足够复杂,请拥抱 React 全家桶

2,100 阅读5分钟
原文链接: zhuanlan.zhihu.com
事情起因:如何看待民工叔因为 Teambition 是 React 技术栈而离职?

个人还是很赞同 Teambition 拥抱 React 全家桶的,这篇文章主要是从逻辑推理上来支持这一结论。

前一阵子 Sam Stephenson 在 RailsConf 2016 上发表了主题演讲《Web 开发不应该这么复杂》 ,里面提到一个观点,如果你不是谷歌也不是 Facebook,那么没必要把前端开发整的这么复杂。

但如果你的业务复杂程度已经接近达到了呢?就比如 Teambition。

Teambition 前端的问题和挑战:

第一,原先数据模型层处理得不好,主要是:同步和异步的处理、数据的共享和更新机制,如果要改对,非常困难,而且从底层开始把同步改异步,很可能需要一路往上改到顶。在不换掉老数据层的情况下,有很多遗留问题几乎无法解决。——@徐飞如何看待民工叔因为 Teambition 是 React 技术栈而离职?
  • 信息量较大,导致查询较复杂,其中有部分数据是可复用的,比如说,这么一大片面板,可能几百条任务,但是其中人员可能就20个,所有参与者都在这20个人里面。
  • 如果要做一些比较实时的交互,会比较麻烦,比如说,某个用户修改了头像,某个标签定义修改了文字,都会需要去立刻更新当前界面所有的引用部分。

  • 查询同一种数据,可能是同步的(缓存中获取),可能是异步的(AJAX获取),业务代码编写需要考虑两种情况。
    获取数据和数据的更新通知,写法是不同的,会加大业务代码编写的复杂度。
    每个渲染数据,都是通过若干个查询过程(刚才提到的组合同步异步)组合而成,如何清晰地定义这种组合关系?
    对于已有数据和未来数据,如何简化它们应用同样规则的代码复杂度。
    ——@徐飞流动的数据——使用 RxJS 构造复杂单页应用的数据逻辑

    看到这些描述,从逻辑上应该知道 Teambition 有一个很复杂的前端产品线了吧。

    React 本身其实还算简单的。最简单的理解,一个组件的渲染函数就是一个基于 state 和 props 的纯函数,state 是自己的,props 是外面来的,任何东西变了就重新渲染一遍,是不是很简单?

    但是,如果抛开 React 生态圈现在所有的那些东西,只用 React 本身来做个大型应用,你 hold 得住么?我可以打包票,99% 的开发者 hold 不住。因为大型应用会带来很多规模上的复杂度,比如跨组件通信,多组件共享状态,多人协作的可维护性,大量嵌套组件的性能问题... 等等。这些东西如何处理,都是靠前人填坑才一步步产生了今天的各种设计模式。Flux/Redux 的繁琐,本质上是针对大型应用的复杂度所作出的权衡:用繁琐一些的 API,换长线的可维护性。在规模不够大的应用里,这些问题并不那么明显,那么这些繁琐的 API 也就显得有些过度设计了。

    Dan Abramov 自己在推上多次强调过,Redux 的设计是以几个原则为优先的:要让状态的变化可追踪,可重复,可维护。为了达成这个目的,才会有 reducer, action, action creator, middleware 这些概念。本来一个 callApi(res => a.b = res) 可以做到的事情,现在你需要先写全套然后配上 thunk middleware 才能做到。因此在规模不够的应用里使用 Redux 肯定会觉得杀鸡用牛刀。然而 React 生态圈里面之前并没有适合中小规模应用的状态解决方案,因为 Flux 从一开始就是冲着 Facebook scale 去设计的,并没有考虑中小规模的应用。最近 MobX 也算是在 React 生态圈里搞出点小动静,就是因为它填补了这个空白,然而用 React + MobX 本质上就是一个更繁琐的 Vue。

    如果做个比较的话,Vue 本身不加任何库就可以很好地满足中小规模应用的需求,配合 Vuex 可以满足大规模应用的需求。同时由于 Vue 的依赖追踪机制,不管 1.0 还是 2.0 都不存在过渡重渲染的性能问题,shouldComponentUpdate / reselect / ImmutableJS 之类的统统不需要。

    其实本来没想提到 Vue 的,只是因为有些人的答案里面非要拿 Vue 来比较。

    回到题主最早的问题,我们需要 React/Redux 么?从可维护性的角度考虑,大型应用确实需要,但这不代表任何规模的应用都得用它,更不代表它就是最好的。如果一个方案能够用更简洁的方式满足你的项目对应规模的可维护性需求,并且让你用得爽,那就相信你自己的心,不要因为 React 教徒云里雾里的宣传看上去很厉害就盲从。——@尤雨溪我们为什么需要React?》(加重加粗是我加的

    接下来对比技术选型:

    @徐飞 (前 Teambition (前端架构师 || 前端 Leader)):TypeScript,RxJS,Vue

    @博深(主导 Teambition React 重构的负责人): React + Redux + Redux Observable + rxjs sdk + 原有的 Backbone

    很多 React 用户喜欢标榜 React is not easy, but it is simple... 我想说,Life is short, easy is underrated.——@尤雨溪我们为什么需要React?

    我想说的是,Life is short, don't repeat other battle-tested solutions until you have to.(人生苦短,如无必要,少造轮子)既然 Facebook 造了 React 这一套出来且 hold 住了业务,为什么不接受呢?相比起 rxjs 这一套,React 全家桶才是成熟解决方案吧。


    既然达到了这个复杂度,无论是从社区生态、改造成本、健壮性还是长远方面来考虑,拥抱 React 全家桶吧。


    React + Redux/Flux + (GraphQL + Relay)/Apollo + Flow + Jest