如何在不编写复杂代码的情况下,构建面向未来的React应用程序
这些简单的提示将帮助您构建易于测试,更新和超级灵活的React应用程序。编写出色的代码并不一定很复杂。不幸的是,我们经常在构建应用程序时没有考虑它们将如何演变以适应未来的变化。
这些技术将如何成为救命稻草
以下是一些常见的场景,在这些场景中,这些小技术将证明是救命稻草:
易于测试。
适应未来的更新。
业务逻辑的分离。
可预测的数据流。
编写面向未来的组件
在编写组件时,请始终记住以下拇指规则:
UI 组件应始终不知道网络请求、业务逻辑或应用状态。
组件应该像纯函数一样编写。它只是意味着,当提供相同的道具时,它应该始终呈现相同的数据。
有关编写出色组件的详细指南。查看本指南。
使用 HOC 使进化变得简单
反应高阶组件 (HOC) 是接受组件并返回组件的组件。
在编写 HOC 时,请始终记住以下拇指规则:
总是喜欢创建那些不创建任何道具的HOC。如果您的 HOC 需要创建道具,请始终确保它不会创建多个道具。
当该行为由应用中的多个组件或所有组件使用时,请使用 HOC。
确保该组件可以在没有 HOC 的情况下工作。组件不应创建与 HOC 的依赖关系。
组件可以直接包装在 HOC 中,而无需向其添加其他逻辑。
为干净的代码构建应用
切勿在单个位置混合视图呈现问题、数据处理和数据提取。混合所有东西将导致意大利面条式建筑,并且将来会变得痛苦。
始终使组件尽可能愚蠢。组件应始终在给定相同状态的情况下呈现相同的内容。
Flux 体系结构允许你为应用创建可预测的数据流。在此体系结构事件中,侦听器侦听用户输入处理程序和网络请求处理程序等内容。当事件侦听器获取它们时,它会将操作调度到存储。仅当调度操作时,状态才会更新。
在以下场景中使用基于通量架构的库,如反流、Redux 等:
该组件使用网络请求或设备 API。
具有通用的应用程序状态。
该组件需要与应用的其他部分共享的业务逻辑或数据操作逻辑。
使用通量架构不仅可以让您构建高度灵活的 UI 组件,还可以将业务逻辑等内容与组件分开。它将允许您轻松迁移到不同的数据获取技术。可预测的单向数据流将使你的应用易于调试和测试。
将化简器视为应用的核心,将调度程序视为适配器。与其在组件中混合业务逻辑,不如将它们放在 Redux(或您正在使用的任何内容)中,并使用操作创建者触发状态更改。