成都网站建设设计

将想法与焦点和您一起共享

可靠React组件设计的7个准则之SRP

我喜欢React组件式开发方式。你可以将复杂的用户界面分割为一个个组件,利用组件的可重用性和抽象的DOM操作。

让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:域名注册虚拟主机、营销软件、网站建设、新邱网站维护、网站推广。

基于组件的开发是高效的:一个复杂的系统是由专门的、易于管理的组件构建的。然而,只有设计良好的组件才能确保组合和复用的好处。

尽管应用程序很复杂,但为了满足最后期限和意外变化的需求,你必须不断地走在架构正确性的细线上。你必须将组件分离为专注于单个任务,并经过良好测试。

可靠React组件设计的7个准则之SRP

不幸的是,遵循错误的路径总是更加容易:编写具有许多职责的大型组件、紧密耦合组件、忘记单元测试。这些增加了技术债务,使得修改现有功能或创建新功能变得越来越困难。

编写React应用程序时,我经常问自己:

  • 如何正确构造组件?

  • 在什么时候,一个大的组件应该拆分成更小的组件?

  • 如何设计防止紧密耦合的组件之间的通信?

幸运的是,可靠的组件具有共同的特性。让我们来研究这7个有用的标准(本文只阐述 SRP,剩余准则正在途中),并将其详细到案例研究中。

单一职责

当一个组件只有一个改变的原因时,它有一个单一的职责。

编写React组件时要考虑的基本准则是单一职责原则。单一职责原则(缩写:SRP)要求组件有一个且只有一个变更的原因。

组件的职责可以是呈现列表,或者显示日期选择器,或者发出 HTTP 请求,或者绘制图表,或者延迟加载图像等。你的组件应该只选择一个职责并实现它。当你修改组件实现其职责的方式(例如,更改渲染的列表的数量限制),它有一个更改的原因。

为什么只有一个理由可以改变很重要?因为这样组件的修改隔离并且受控。单一职责原则制了组件的大小,使其集中在一件事情上。集中在一件事情上的组件便于编码、修改、重用和测试。

下面我们来举几个例子

实例1:一个组件获取远程数据,相应地,当获取逻辑更改时,它有一个更改的原因。

发生变化的原因是:

  • 修改服务器URL

  • 修改响应格式

  • 要使用其他HTTP请求库

  • 或仅与获取逻辑相关的任何修改。

示例2:表组件将数据数组映射到行组件列表,因此在映射逻辑更改时有一个原因需要更改。

发生变化的原因是:

  • 你需要限制渲染行组件的数量(例如,最多显示25行)

  • 当没有要显示的项目时,要求显示提示信息“列表为空”

  • 或仅与数组到行组件的映射相关的任何修改。

你的组件有很多职责吗?如果答案是“是”,则按每个单独的职责将组件分成若干块。

如果您发现SRP有点模糊,请阅读本文。 在项目早期阶段编写的单元将经常更改,直到达到发布阶段。这些更改通常要求组件在隔离状态下易于修改:这也是 SRP 的目标。

1.1 多重职责陷阱

当一个组件有多个职责时,就会发生一个常见的问题。乍一看,这种做法似乎是无害的,并且工作量较少:

  • 你立即开始编码:无需识别职责并相应地规划结构

  • 一个大的组件可以做到这一切:不需要为每个职责创建组成部分

  • 无拆分-无开销:无需为拆分组件之间的通信创建 props 和 callbacks

这种幼稚的结构在开始时很容易编码。但是随着应用程序的增加和变得复杂,在以后的修改中会出现困难。同时实现多个职责的组件有许多更改的原因。现在出现的主要问题是:出于某种原因更改组件会无意中影响同一组件实现的其它职责。

可靠React组件设计的7个准则之SRP

不要关闭电灯开关,因为它同样作用于电梯。

可靠React组件设计的7个准则之SRP

这种设计很脆弱。意外的副作用是很难预测和控制的。

例如, 同时有两个职责,绘制图表,并处理为该图表提供数据的表单。 就会有两个更改原因:绘制图表和处理表单。

当你更改表单字段(例如,将 修改为