在React团队工作期间，我有幸看到了Jordan、Sebastian、Sophie和其他团队成员是如何解决问题的。在这篇文章中，我将从他们那里学到的东西浓缩成一个高级技术指南。这些准则不一定是详细的。这些是我对React团队的观察和整理——其他团队成员可能有其他观点。UIoverAPI当我们将抽象的概念大规模地付诸实践时，难免会出现怪异的情况。这些怪癖如何在UI中表现出来？你能看出应用程序中涉及哪些特定的抽象吗？抽象对用户体验有直接影响——它创造了良好的、一致的体验或限制了某些东西。这就是为什么当我们设计API时，我们不会从抽象本身开始。相反，我们将从用户体验开始，然后回到抽象。有时当我们回到抽象时，我们发现必须改变整个方法才能实现正确的用户体验。如果我们首先从API开始，我们将无法检测到这一点。因此，我们先考虑UI，再考虑API。吸收复杂性和简化React内部的实现不是我们的目标。如果产品开发者可以使用React编写更易于理解和修改的代码，我们很乐意将React的内部实现复杂化。我们希望使产品开发更加负责并易于协作。这意味着我们必须将负责的部分封装在React中。React不能拆分成小的、松散耦合的模块，因为那是行不通的。React的使命是扮演协调者的角色。通过提高抽象级别，它使产品开发人员更加强大。产品开发受益于React的可预测和完整系统。这意味着我们引入的每个新功能都必须与现有功能兼容。在React中设计和实现新功能很困难。这就是为什么我们的核心功能没有收到太多的开源贡献。我们吸收复杂的部分并防止它们污染生产代码。从Hacks到Idioms的每个Api都有一些限制。有时这些限制会阻止我们创造良好的用户体验。为此，我们提供了一些逃生通道，以供需要时使用。黑客攻击不是长久之计，因为它们很脆弱。开发人员必须决定他们是维护、支持这些黑客攻击，还是以牺牲用户体验为代价移除黑客攻击。通常大多数人会牺牲用户体验，否则这些hack可能会阻碍用户优化。我们需要让产品开发人员使用这个回退，看看它在实践中是如何工作的。我们的目标是为这种实现提供一个通用的解决方案（idiomaticsolution），以达到更好的用户体验。有时一个解决方案需要我们花费数年时间。我们更喜欢弹性黑客来建立完整的习语（一个糟糕的习语）。要实现局部开发，不能在代码编辑器中做太多的事情。您可以添加几行并删除几行。或者复制粘贴。但是许多抽象使这些基本操作变得困难。例如，MVC框架使得删除某些渲染变得不可靠。这是因为即使你删除了childern的方法，parent仍然有可能执行它。相比之下，React的优势在于您通常可以安全地删除渲染树中的一些代码。在设计API时，我们假设使用它的人只熟悉他们将使用的代码部分。如果预期的效果只出现在这部分代码中，我们就会避免出现意想不到的结果。例如，我们经常假设新代码是安全的。在删除和修改代码时，应明确指出这些更改将影响应考虑的部分。我们不应该假设更改单个文件需要了解整个代码。如果更改不安全，我们希望开发人员尽早发现更改的影响。虽然可以使用警告、类型检查和开发人员工具来提供帮助，但它们都受到API设计的限制。如果API不够本地化，则本地开发是不可能的。例如，findDOMNode不是一个好的API，因为它需要全面的知识。渐近复杂性一些框架选择在开发路径中分叉，提供两条路线：简单的方法或强大的、完整的方法。简单的方法很容易学习，但你最终会达到它的极限。这时候就得另起炉灶，用另一种方法来实现。我们认为实现一个复杂的东西和实现一个简单的东西在结构上没有太大区别。我们不提供编写简单状态的简单方法，因为这会导致开发中出现分支。如果我们认为开发者在开发过程中想要完整的开发工具，我们愿意牺牲低门槛来实现这一点。有时候，[简单]和[强大]代表两种不同的框架，这时就需要换框架重写，这种事情最好避免。以React为例，添加服务器端渲染等优化将需要额外的努力，但您不需要完全重写。控制自上而下方法（例如代码评估）造成的损害很重要。时间长了，我们的标准会下降，功能会在死线前完成，我们可能不会继续维护产品。我们不能指望每个人都遵守规则，React作为协调者必须控制损害。如果一些UI相关的代码非常慢，我们需要尽一切可能防止它拖慢加载时间并防止它影响其他UI性能。理想的情况是开发者只需为他们使用的功能支付开发成本，产品用户只需加载他们将要使用的UI。并发模式，包括时间切片和选择性水化，可以通过不同的方式实现。由于代码库本身性能比较稳定，应用代码没有底线。所以我们倾向于控制应用程序代码中的损坏，而不是修复代码库中的代码。相信理论有时我们知道某些实践是死胡同。也许它现在可以工作，但想象一下它的局限性。本来就不可能依靠它来达到理想的用户体验。我们一有机会就摆脱困境。我们不想被困在这里。如果某种方法在理论上更站得住脚，即使要画几年，我们也愿意投入精力。一路上会有许多障碍和务实的妥协。但我们知道，如果我们继续克服这些困难，实践终将获胜。你的团队的原则是什么？以上是我在React团队工作时观察到的基本原则，但我可能漏掉了很多。我也没有提到React是如何推出API的，团队如何传达未来变化的方向等等。也许我们可以下次再谈。你的团队的指导方针是什么？我洗耳恭听。
