摘要：幸运的是，组合易于理解。组件的组合是自然而然的。高效用户界面可组合的层次结构，因此，组件的组合是一种构建用户界面的有效的方式。这个原则建议避免重复。只有一个组件符合单一责任原则并且具有合理的封装时，它是可复用的。
翻译：刘小夕原文链接：https://dmitripavlutin.com/7-...
原文的篇幅非常长，不过内容太过于吸引我，还是忍不住要翻译出来。此篇文章对编写可重用和可维护的React组件非常有帮助。但因为篇幅实在太长，我对文章进行了分割，本篇文章重点阐述 组合和复用。因水平有限，文中部分翻译可能不够准确，如果你有更好的想法，欢迎在评论区指出。
更多文章可戳: https://github.com/YvetteLau/...
———————————————我是一条分割线————————————————
组合一个组合式组件是由更小的特定组件组合而成的。
组合（composition）是一种通过将各组件联合在一起以创建更大组件的方式。组合是 React 的核心。
幸运的是，组合易于理解。把一组小的片段，联合起来，创建一个更大个儿。
让我们来看一个常见的前端应用组合模式。应用由头部的 header、底部的 footer、左侧的 sidebar，还有中部的有效内容联合而成：
function Application({ children }) {
return (
{children}
);
}
function Header() {
return (
)
}
function Footer() {
return (
)
}
function Sidebar({ children }) {
return (
{children}
);
}
function Content({ children }) {
return (
{children}
)
}
function Menu() {
return (
);
}
function Article() {
return (
);
}
function Label({ children }) {
return <{children}>
}
const app = (
);
ReactDOM.render(app, document.getElementById("root"));
应用程序演示了组合如何构建应用程序。这种组织这样组织代码即富于表现力又便于理解。
React 组件的组合是自然而然的。这个库使用了一个声明范式，从而不会抑制组合式的表现力。
那么组合与单一责任以及封装有什么联系呢？让我们一起看看：
单一责任原则描述了如何将需求拆分为组件，封装描述了如何组织这些组件，组合描述了如何将整个系统粘合在一起。组合的好处 单一责任
组合的一个重要方面在于能够从特定的小组件组成复杂组件的能力。这种分而治之的方式帮助了被组合而成的复杂组件也能符合 SRP 原则。
回顾之前的代码片段，
将此职责分为四个子职责是有意义的，每个子职责由专门的组件实现，分别是
现在来看看组合的好处：通过子组件分别实现单一职责的方式，使
组合有可重用的有点，使用组合的组件可以重用公共逻辑，
例如，组件
const instance1 = (
/* Specific to Composed1 code... */
/* Common code... */
);
const instance2 = (
/* Common code... */
/* Specific to Composed2 code... */
);
代码复制是一个不好的实践(例如更改 Composed1 的代码时，也需要去更改Composed2 中的代码)，那么如何使组件重用公共代码？
首先，将共同代码封装到一个新组件中，如
首先，在新组件中封装公共代码。其次，
const instance1 = (
);
const instance2 = (
);
可重用的组件符合不重复自己(Don"t repeat yourself)的原则。这种做法可以节省你的精力和时间，并且在后期，有利于代码维护。
灵活在 react 中，一个组合式的组件通过给子组件传递 props 的方式，来控制其子组件。这就带来了灵活性的好处。
例如，有一个组件，它需要根据用户的设备显示信息，使用组合可以灵活地实现这个需求：
function ByDevice({ children: { mobile, other } }) {
return Utils.isMobile() ? mobile : other;
}
{{
mobile: Mobile detected!,
other: Not a mobile device
}}
用户界面可组合的层次结构，因此，组件的组合是一种构建用户界面的有效的方式。
注：DRY 原则理论上来说是没有问题的，但在实际应用是切忌死搬教条。它只能起指导作用，没有量化标准，否则的话理论上一个程序每一行代码都只能出现一次才行，这是非常荒谬的，其它的原则也是一样，起到的也只是指导性的作用。
复用可重用的组件，一次编写多次使用。
想象一下，如果软件开发总是重复造轮子。那么当你编写代码时，不能使用任何已有库或工具。甚至在同一个应用中你都不能使用已经编写过的代码。在这种环境中，是否有可能在合理的时间内编写出一个应用呢？绝无可能。
此时应该到认识重用的重要性，使用已有的库或代码，而不是重复造轮子。
应用内的复用根据“不要重复自己”（DRY）原则，每一条知识都必须在系统中具有单一，明确，权威的表示。这个原则建议避免重复。
代码重复增加了复杂性和维护工作，但没有增加显著的价值。逻辑更新迫使您修改应用程序中的所有重复代码。
重复问题可以用可复用组件来解决。一次编写，多次使用。
但是，复用并非毫无成本。只有一个组件符合单一责任原则并且具有合理的封装时，它是可复用的。
符合单一职责原则是必须的：
复用一个组件实际上就意味着复用其职责
只有一个职责的组件是最容易复用的。
但是，当一个组件错误地具有多个职责时，它的复用会增加大量的开销。你只想复用一个职责实现，但也会得到不必要的职责实现。比如，你只是想要一个香蕉，但是在你得到一个香蕉的同时，不得不被迫接受所有的丛林。
合理封装的组件。隐藏了内部实现，并且有明确的 props ，使得组件可以使用与多种需要复用的场合。
复用第三方库某个工作日，你刚刚收到了为应用增加新特性的任务，在撩起袖子狂敲代码之前，先稍等几分钟。
你要做的工作在很大概率上已经被解决了。由于 React 非常流行以及其非常棒的开源社区，先搜索一下是否有已存在的解决方案是明智之举。
查看 brillout/awesome-react-components ，它有一个可复用的组件列表。
优秀的第三方库有结构性的影响，并且会推广最佳实践。以我的经验而言，最有影响的当属 react-router 和 redux。
react-router 使用了声明式的路由来构建一个单页应用。使用
redux 和 react-redux 引入了单向和可预测的应用状态管理。可以将异步的和非纯的代码（例如 HTTP 请求）从组件中提取出来，从而符合单一职责原则并创建出 纯（pure）组件 或 几乎纯（almost-pure）的组件。
这里是一份检查清单可以确定第三方库是否值得使用，：
文档：检查库是否具备有意义的 README.md 文件和详细的文档
测试过的：可信赖库的一个显著特征就是有高的测试覆盖率
维护：看看库作者创建新特性、修改bug及日常维护的频率
最后谢谢各位小伙伴愿意花费宝贵的时间阅读本文，如果本文给了您一点帮助或者是启发，请不要吝啬你的赞和Star，您的肯定是我前进的最大动力。https://github.com/YvetteLau/...
关注小姐姐的公众号，加入交流群。文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/106659.html
摘要：单元测试不仅涉及早期错误检测。当组件的架构设计很脆弱时，就会变得难以测试，而当组件难以测试的时候，你大概念会跳过编写单元测试的过程，最终的结果就是组件未测试。可测试性是确定组件结构良好程度的实用标准。可复用的组件是精心设计的系统的结果。 翻译：刘小夕原文链接：https://dmitripavlutin.com/7-... 本篇文章重点阐述可测试和富有意义。因水平有限，文中部分翻译可...
摘要：编写组件时要考虑的基本准则是单一职责原则。这些更改通常要求组件在隔离状态下易于修改这也是的目标。解决多重责任问题需要将分割为两个组件和。组件之间的通信是通过实现。更改的唯一原因是修改表单字段。 翻译：刘小夕原文链接：https://dmitripavlutin.com/7-... 原文的篇幅非常长，不过内容太过于吸引我，还是忍不住要翻译出来。此篇文章对编写可重用和可维护的React组...
摘要：组件可以处理其他组件的实例化为了避免破坏封装，请注意通过传递的内容。因此，将状态管理的父组件实例传递给子组件会破坏封装。让我们改进两个组件的结构和属性，以便恢复封装。组件的可重用性和可测试性显著增加。 翻译：刘小夕原文链接：https://dmitripavlutin.com/7-... 原文的篇幅非常长，不过内容太过于吸引我，还是忍不住要翻译出来。此篇文章对编写可重用和可维护的Re...
摘要：函数式编程与面向对象编程编程的本质之剑目录编程的本质读到两篇文章写的不错综合摘录一下复合是编程的本质函数式程序员在洞察问题方面会遵循一个奇特的路线。在面向对象编程中，类或接口的声明就是表面。 函数式编程与面向对象编程[5]:编程的本质 之剑 2016.5.6 01:26:31 编程的本质 读到两篇文章,写的不错, 综合摘录一下 复合是编程的本质 函数式程序员在洞察问题方面会遵循...
摘要：删除不必要的代码。而简化前的代码包含的语法要素对于传达代码意义本身作用并不大。删除不必要的代码有时候，我们试图为不必要的事物命名。例如，大多数情况下，你应该省略仅仅用来当做返回值的变量。你的函数名应该已经说明了关于函数返回值的信息。 原文地址 本文已在前端早读课公众号首发：【第952期】JavaScript代码风格要素 译者：墨白 校对：野草 1920年，由威廉·斯特伦克(Will...
阅读 1044·2021-11-24 09:38
阅读 1141·2021-11-23 09:51
阅读 3117·2021-11-16 11:44
阅读 1936·2021-09-22 15:52
阅读 1773·2021-09-10 11:20
阅读 1477·2019-08-30 13:47
阅读 1400·2019-08-29 12:36
阅读 3411·2019-08-26 10:43
