翻译：刘小夕
原文链接：https://dmitripavlutin.com/7-architectural-attributes-of-a-reliable-react-component/
原文的篇幅非常长，不过内容太过于吸引我，还是忍不住要翻译出来。此篇文章对编写可重用和可维护的React组件非常有帮助。但因为篇幅实在太长，我不得不进行了分割，本篇文章重点阐述 SRP，即单一职责原则。
————————我是一条分割线——————
我喜欢React组件式开发方式。你可以将复杂的用户界面分割为一个个组件，利用组件的可重用性和抽象的DOM操作。
基于组件的开发是高效的：一个复杂的系统是由专门的、易于管理的组件构建的。然而，只有设计良好的组件才能确保组合和复用的好处。
尽管应用程序很复杂，但为了满足最后期限和意外变化的需求，你必须不断地走在架构正确性的细线上。你必须将组件分离为专注于单个任务，并经过良好测试。
不幸的是，遵循错误的路径总是更加容易：编写具有许多职责的大型组件、紧密耦合组件、忘记单元测试。这些增加了技术债务，使得修改现有功能或创建新功能变得越来越困难。
编写React应用程序时，我经常问自己：
幸运的是，可靠的组件具有共同的特性。让我们来研究这7个有用的标准(本文只阐述 SRP，剩余准则正在途中)，并将其详细到案例研究中。
单一职责
当一个组件只有一个改变的原因时，它有一个单一的职责。
编写React组件时要考虑的基本准则是单一职责原则。单一职责原则(缩写：SRP)要求组件有一个且只有一个变更的原因。
组件的职责可以是呈现列表，或者显示日期选择器，或者发出 HTTP 请求，或者绘制图表，或者延迟加载图像等。你的组件应该只选择一个职责并实现它。当你修改组件实现其职责的方式（例如，更改渲染的列表的数量限制），它有一个更改的原因。
为什么只有一个理由可以改变很重要？因为这样组件的修改隔离并且受控。单一职责原则制了组件的大小，使其集中在一件事情上。集中在一件事情上的组件便于编码、修改、重用和测试。
下面我们来举几个例子
实例1：一个组件获取远程数据，相应地，当获取逻辑更改时，它有一个更改的原因。
发生变化的原因是：
示例2：表组件将数据数组映射到行组件列表，因此在映射逻辑更改时有一个原因需要更改。
发生变化的原因是：
你的组件有很多职责吗？如果答案是“是”，则按每个单独的职责将组件分成若干块。
如果您发现SRP有点模糊，请阅读本文。
在项目早期阶段编写的单元将经常更改，直到达到发布阶段。这些更改通常要求组件在隔离状态下易于修改：这也是 SRP 的目标。
1.1 多重职责陷阱
当一个组件有多个职责时，就会发生一个常见的问题。乍一看，这种做法似乎是无害的，并且工作量较少：
这种幼稚的结构在开始时很容易编码。但是随着应用程序的增加和变得复杂，在以后的修改中会出现困难。同时实现多个职责的组件有许多更改的原因。现在出现的主要问题是：出于某种原因更改组件会无意中影响同一组件实现的其它职责。
不要关闭电灯开关，因为它同样作用于电梯。
这种设计很脆弱。意外的副作用是很难预测和控制的。
例如，
当你更改表单字段（例如，将
