【react】走进React核心团队

当我第一次来到Facebook的React团队工作时，我有点茫然不知所措。从外部看，React核心团队规模看起来很庞大！但事实是，像Eli White和Sebastian McKenzie这样的人都是React Native团队的人。当你想到React的时候，你会想起很多著名的trainers（培训师），但是他们实际上跟Facebook或react核心团队都是不沾边的。除了这些人，如果再加上所有支持React社区的开源库（比如Chakra UI和Framer Motion）的维护者，突然间“React核心团队的成员”看起来可以填满一个体育场！但事实恰恰相反。

实际上，React核心团队是很小的-Sebastian Markbage，Luna Ruan，Dan Abramov，Andrew Clark，Brian Vaughn，Rick Hanlon，Seth Webster，Christine Abernathy和我自己（Rachel Nabors）。虽然Dan是大多数人想到React时会想到的人，但是请不要忘记了，Sebastian是创始团队成员之一，虽然是剩下的最后一位。尽管Sebastian并未发明React（Jordan Walke才是react的发明人），但他仍然是团队前进方向的指明灯-他负责考虑如何将每一个feature融入到宏大的react架构中。Dan和Andrew共同创建Redux.js。 Brian创建了React DevTools。Rick是一位高等数学的布道者。 Luna跟Relay合作，负责处理react在数据方面的事务，并且是团队中唯一主修计算机科学的人！Christine与大学合作，将React Native教育带给人数小众，不被重视的地方。Seth担任我们的团队经理。而我是从事React的文档和教育材料方面的工作。

但是，如果您足够了解这个团队的话，您可能会惊讶地发现，Andrew十分钟爱卡拉OK，Seth曾经是一个表演音乐家，而Brian现在正积极地录制他自己的音乐（加分项-他的猫也是非官方的团队吉祥物），Rick积极参加社会正义运动。Dan跳舞可以跳一整晚。Christine看完了漫威（Marvel Cinematic Universe）的所有电影，Luna跟我分享了对优质普洱茶的热爱，Sebastian业余时间花了很多时间学习木工！

在Facebook内部，React是许多令人惊叹的项目生态系统的一部分，这些项目不断相互影响，有些是开源的，有些则没有。 Facebook的工程文化就像解决方案的“反应堆”。 React本身是内部创建以解决相同UI挑战的几个库之一。 React从它们之中脱颖而出，并很快进入开源社区！现在，尽管React依然在激发着公司的其他UI框架，库和解决方案，但React Core团队的运作就像一个独立的，短小精悍的研发实验室。尽管与标准组织的运作方式并不完全相同，但是使用React Core会让我想起使用W3C。它几乎就像一个Working Group一样运作。它的使命是：致力于使开发人员更轻松地编写一致的，可响应的，可重用的UI。

当标准机构考虑向浏览器空间引入新规范时，规范作者在完成API的最终设计之前会谨慎地工作。对于众多浏览器开发人员来说，每个API的实现都意味着巨大的代码提交量。同样，React核心团队上的工程师的工作也会影响到许多代码库，因此必须谨慎。特性开发从深入讨论和充分辩论开始。想法一旦丰满起来，就会在Facebook的项目中进行“活实验”。这样，每一个特性在其成为RFC（Request for Comments，征求意见），进入react社区之前，它会经过了充分的测试，“死胡同”和坏主意会伴随它们的代码一起被移除到了很少有人见过的【React代码垃圾场】。虽然一个新的规范可以“破坏互联网”（也可以参见命运多舛的XHTML2），但是因为升级到新的React版本对于维护人员来说完全是自愿的。所以，引入新特性的重点在于易于迁移和与现有库的兼容性。

即使一个想法可能在幕后“失败”，但从长远来看，它仍然可以结为React团队带来收益。2015年，团队尝试将React带到worker中执行以提升性能。结果发现，来回传递数据的开销超出了预期。虽然实验最终失败了，但它激发了更多的灵感。如果组件可以分为在主线程上执行的组件和在worker线程中执行的组件，那么为什么它们不能分为在服务器执行的组件和在浏览器上执行的组件呢？五年后，这个想法形成了React团队几天前宣布的Server Components想法的基础。

同样的，在2018年，React团队与Prepack团队合作。他们希望通过删除在构建时可能发生的任何计算来自动优化React组件。这次合作花了两个团队几个月的努力！最后，优化代价过高，实验宣告“失败了”。然而，从那次实验中学到的东西却为当年稍后提出的hook设计提供了参考。这次实验还表明，单靠编译不足以优化性能。事实是，您想要优化的大部分代码都依赖于编译器无法知道的动态条件---但是服务器能知道！这是两年后导致Server Components特性出现的另外一个洞察。

当人们在讲台上看到Dan或阅读Luna关于【新JSX转换】的发行说明文章的时候，他们往往忽略了一个真相：除了像Hooks这样被发布出来的特性之外，还有很特性还在到达RFC阶段的路上。这些特性要么是准备得不够充分，要么是因为无情的优先级，被留在了会议室的白板上，要么是需要等到某些被废弃的代码被移除之后才会暴露出来。

在一个如此重视迭代（shipping）并且以越来越快的速度迭代的行业中，当您无法将自己承诺的东西交付给自己或他人时，会感到沮丧。但是不发布新特性并不意味着这个团队没有采取任何的动作。在你看不到的“月球背面”，团队正在做： 1）思考和计划；2）不断地试验和得出结论。排除死胡同，“失败”的尝试都不是徒劳无功的。它们都是指向最终解决方案的路标。

即使你还没有完成今年年初的工作计划，也请不要沮丧。你要相信挫折和变化是常态，而不是把它们看作难以接受的意外或者倒霉运气。即使在看待React这件事情上，也是一样的。 React Core团队非常重视以正确的方式做正确的事。这句话意味着在经历一个低谷时要保持耐心，无论是情感上还是技术上。这句话还意味着寻求帮助和聆听旁人意见，而不是试图独自去完成所有事情。这句话更意味着你要有信心，不能仅仅因为自己没有持续的对外的产出和对外的动作，就说自己没有提供相应的价值，从而自我否定。