关闭

【译】React团队的技术准则

时间: 2020-01-06阅读: 648标签: 技术
本文翻译自react团队核心成员Dan Abramov的技术博客。地址:https://overreacted.io/
本文首发于公众号:符合预期的CoyPan

我React团队工作的这段时间,很幸运能够看见 JordanSebastianSophie 和其他团队成员是如何解决问题的。在本文中,我会把从他们身上学到的,浓缩为一篇较高层次的技术准则。这些准则未必详细。它们都是我对React团队的观察和整理 —— 其他团队成员或许有其他的观点。


UI优先于API

当我们把抽象概念大规模用于实践时,难免会有怪异之处。这些怪异之处是如何在用户界面上呈现的呢?你能看出一个应用中包含了哪些特定的抽象概念么?

抽象概念对用户体验有直接的影响 —— 它能创造好的、延续性的的体验或者限制某些东西。这也是为什么我们在设计API时,并不会从抽象本身开始。相反地,我们会从用户体验开始,然后再回到抽象概念。

有时候当我们回到抽象概念时,会发现必须更改整个方法,才能达到正确的用户体验。如果我们先从API下手,就无法察觉到这点。所以,我们将UI放在API之前考虑。


吸收复杂性

简化React内部的实现并不是我们的目标。如果产品开发者可以使用React写出更易于理解、易于修改的代码,我们乐于把React的内部实现变得复杂。

我们想把产品的开发变得更加职责分明,易于合作。这意味着我们必须把负责的部分封装在React的内部。React不能被切分为小规模、耦合松散的模块,因为这样便无法工作。React的使命是成为协调者的角色。

通过提升抽象层级,使得产品开发者更加有力。产品开发会从React的可预测的完备系统中受益。这意味着我们推出的每一个新功能,都必须兼容已经存在的功能。设计和实现React的新功能十分困难。这也是我们核心功能并没有收到太多开源贡献的原因。

我们吸收了复杂的部分,防止他们污染产品的代码。


从Hacks到Idioms

每一个Api都有一些局限性。有时,这些限制会妨碍我们打造良好的使用者体验。为此,我们提供了一些后路(escape hatches)以供需要时使用。

Hacks并不是长久之计,因为他们很脆弱。开发者必须决定他们是否维护,支持这些Hack,或者移除hack而牺牲用户体验。通常大多数人会牺牲用户体验,不然这些hack也会有可能阻碍用户的优化。

我们需要让产品开发者使用这个后路,并观察在他们实践中都是如何使用的。我们的目标是提供这类实现一个常用的解决方法(idiomatic solution),目的是达成更好的用户体验。有时候,一个解决方案,会花费我们数年的时间。我们更倾向于有弹性的hack来确立完整的习惯用法(a poor idiom)。


实现局部开发

你无法在代码编辑器做太多的事情。你可以增加几行,移除几行。或者复制粘贴。但许多抽象概念让这些基本操作变得困难。

比如,MVC框架让删除一些render的操作变得不可靠。这是因为及即使你删除了childern的方法,parent仍有可能执行它。相比之下,React的优势在于:你通常能安全的删除某些render tree内的代码。

在设计API时,我们会假设使用它的人只熟悉他们会用到的局部代码的相关知识。如果预期发生的影响只发生在这局部的代码中,我们将会避免意料之外的结果。例如,我们通常假设新增代码时安全的。在移除和修改代码时,应该清楚指出这些改动会连带影响、应该被考虑到的部分。我们不应该假设改动单一文件需要对整个代码都了解。

如果某一项改动不安全,我们希望开发者能够尽早发现这个改动所带来的的影响。虽然可以使用警告、类型检查和开发者工具来帮忙,但它们都受限于API的设计。如果API不够局部性,局部开发就不可能实现。例如,findDOMNode就不是一个好的API,因为它需要全面的了解。


渐进的复杂度

有些框架会选择在开发的路上分出岔路,提供两种路线:简单的方法或强大、完整的方法。简单的方法容易学习,但你终究会走到他的极限。这个时候,你必须推倒重来,重新使用另外一套方法来实现。

我们认为实现一个复杂的东西,和实现一个简单的东西,在结构上没有太大的差别。我们并不会简单的状态提供简单的写法,因为这样会使开发中出现岔路。如果我们认为开发者在开发过程中想要完整的开发工具,我们愿意牺牲低门槛来达成这件事。

有时,【简单】和【强大】代表两种不同的框架,那么你扔需要换框架重写,最好能避免这种事。以React为例,增加服务端的render这类的优化会需要付出额外的努力,但你不需要完全的重写。


控制损害

从上到下的解决方式很重要,例如代码评估。然后长时间下来,我们的标准会下降,功能会在dead line前完成,也有可能不继续维护产品。我们无法期待所有人都遵守规则,身为协调者的React必须控制损害。

如果有些UI相关的代码很慢,我们需要想尽一切办法,避免它拖慢载入时间,避免它影响其他的UI表现。最理想的状况是,开发者只会为了他们使用到的功能付出开发成本,而产品使用者只需要载入他们会用到的UI。Concurrent Mode ,包括 Time Slicing 和 Selective Hydration ,可以以不同的方式达到理想状态。

由于代码库本身的性能相对稳定,而应用的代码没有底线。因此我们倾向于在应用代码中去控制损害,而不是去修正代码库内的代码。


相信理论

有时我们会知道某些做法是死路一条。也许它现在可以运作,但可以想象它的局限。本质上无法依靠它来实现想要的用户体验。一旦有机会,我们会立刻从这种情况中抽身。

我们不想卡在这里。如果某种做法在理论上更站得住脚,就算画上好几年,我们也愿意在上面投入精力。在达成目标的过程中,会遇到许多障碍和务实的妥协。但我们详细,若持续的客服这些困难,理论终究会获胜。


你们团队的准则是什么

以上是我观察到的React团队在工作时的基本原则,但我可能漏了很多。我也还没提到React如何推出API,团队如何沟通未来的改动方向等等。或许下次可以再来谈谈这些。

站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

链接: http://www.fly63.com/article/detial/7178

写技术文的三个原则是什么?

我关注了很多技术类的公众号,看着大佬的公众号几千的阅读量,甚是羡慕,这直接导致了我没有心情减肥,甚至多吃了一个鸡腿。要怎么才能写出一篇好技术文章,让读到的人感到身心舒畅,快速Get到想说的点,我想破了脑袋。

8大前端开发技术

小程序的横空出世以及Web应用的大量涌现,几乎让整个互联网行业都缺前端工程师。优质的岗位、丰厚的薪资,前端开发成为程序员圈内“钱”途飙升最快的岗位。但火爆形势下,应接不暇的技术迭代,与高质量系统化提升导致的学习资源短缺

未来,哪些技术在前端开发的地位会越来越高?

过去的这段时间里,不论是互联网巨头还是初创企业,都纷纷进行了一波优化。渐趋理智的资本淘汰了一批不能适应市场的业务,而业务的紧缩也淘汰了一批不能适应市场的程序员。

技术追求的误区[观点与思考]

认识的一个 10 人左右的团队,本来是用 PHP 的,这些年看到网上很多用 / 转 Go 的消息,于是团队里有不少人就焦虑了,希望找一个合适的切入时间,能够试一把 Go

那些你不知道运用Js的惊人技术

自2009年Node.js问世以来,JavaScript的用途便不再局限于编写浏览器脚本,Node.js使它可以在服务端运行。不知是不是受到Node.js的启发,如今有很多技术拓展了JavaScript的用途,JS的新鲜玩法有很多

华为面向开发者的十大技术

AI、5G、云计算、大数据等技术都在快速发展,华为也一直未停下创新的步伐。在为千行百业打造技术底座这件事上,华为无疑是最用心的企业之一。现在,基于这 10 大技术,华为势必能为开发者以及各行业构建出更强大

技术开发,如何与领导谈涨薪

归根结底,涨薪其实是达到自己价值与薪资的最佳匹配. 好比你就是一只股票,公司当然会选择那些估值远高于股指的股票. 所以唯有不断增长自己的价值,才会成为你在涨薪谈判中的重要筹码.

bt种子简介与magnet磁力介绍

BT下载相信老司机们都接触过,为什么BT种子会慢慢被磁链取而代之?它们都可以用于BT下载,除了文件和字符串这表面上的区别,背后的技术上又有何不同?

技术人员如何写好周报和日报

前端时间,阿里发布声明,取消了周报制度。虽然阿里取消了周报制度,但还是有很多公司或者部门,依然在写周报。还有团队为此专门开发了周报系统。

WebService的两种方式SOAP和REST,之间的区别与优缺点

SOAP用于在Web Service中把远程调用和返回封装成机器可读的格式化数据。REST形式上应该表述为客户端通过申请资源来实现状态的转换,在这个角度系统可以看成一台虚拟的状态机。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!