https://overreacted.io/what-are-the-react-team-principles/
这篇文章 Dan 帮我们看到 React 团队是如何运作的,有点意思,由于提取精髓,因此略有删减。
整个 APIs 的设计是从用户体验这个视角来出发的,因此这些 APIs 并不是纯的工程角度。那我们知道前端的用户体验主要还是在 UI 的还原上,抽象一层是不是能更好的还原 UI ,这是一个很有意思的设想(这个角度还是还原了前端的本质,我们是搞UI界面的啊,同学们)。
如果你看过 React 的源代码,就能明白其内部实现和结构有多复杂,他们的设想是希望产品的开发人员可以尽可能的简单,并从整个系统中受益,并且如果因为开发者的简单而使 React 变的复杂,他们也愿意进行改动(不怕说代码很脏,结构很乱,只要能解决问题)。
从安全的角度来说 React 团队希望开发者能尽早的发现变更的全部效果,因此会有很多警告以及文字性的描述来提醒开发者,这一点上我也觉得 React 团队的设计,是符合整个社区期望的,如果有一天我们也做开源的事情,我们就必须要很慎重的对待任何的变动,我们必须假设开发者无法理解你的所有实现(尽早的让开发者知道你的变更)。
在复杂和简单中做了一个权衡,选择一个适合自己的路去走,因此 React 的设计会照顾这方面,他们的设想是说,实现复杂的事情和实现简单的事情,并没有什么不同,如果为了实现简单的事情而造成了麻烦,这很不可取(尽早的让用户使用,并得到反馈)。
如果我们已经意识到了某种方法的局限性,并且很阻碍用户体验这一层,他们就会立即放弃,因为他们团队已经形成了一个最大公约数,就是如果有一个方法是有意义的,哪怕多年,他们也会去实现(目标明确,就撸起袖子开搞,直到胜利)。
那么从这个角度来看,我们就能看到很多 React 的运作思路,相信你在控制台肯定也看到过很多信息,这些信息有时候还是很有用的。另外每一个方案,React 团队都是很慎重的去考虑清楚,不过多的干扰,而是从本质上出发,我们的本质是什么?最优的 UI 实现其实就是用户体验。
其实这些设计原则,好像也是我们工作的原则,如果你维护一个产品,或是有一个大的团队一起协作,这些原则其实是可以适用的。