前端架构

一、 数据模型

1.领域模型
领域模型是业务数据，往往要持久化到数据库或localStorage中，属于可跨模块复用的公共数据
减少了代码重复问题，减少网络请求，跨模块数据同步问题不复存在

2.应用状态模型
视图相关的状态数据

二、视图层组件
1.展示型组件
保持职责单一，仅做视图呈现和最基本交互行为，通过props接收数据和回调函数输出结果，
如果展示型组件粒度切分能很好的遵循高内聚低耦合和职责单一原则的话，可以沉淀出很多可复用的通用业务组件。

三、公共服务
所有的HTTP请求放在一起统一管理
日志服务、本地存储服务、错误监控、Mock服务等统一存放在公共服务层；

四、跨模块通信
为避免模块间相互耦合、确保架构长期干净可维护：
不在一个模块内部直接调用其他模块的Dispatch方法（写操作、变更其他模块的state）
不在一个模块内部直接读取其他模块的state方法（读操作）
建议将跨模块通信的逻辑代码放在父模块中，或者在一个叫做Mediator层中单独维护

五、数据流管理
Redux单向数据流，Redux架构的设计核心是单向数据流
1. Action
用户操作行为：click drag input ...
服务端返回数据后续的行为

2. Reducer
每个Action都会对应一个数据处理函数，即Reducer。特别强调，Reducer必须是纯函数（pure function），这个规定带来一个非常大的好处，数据处理层代码变的非常容易写单元测试。
纯函数的特征是入参相同的情况下，返回值恒等，举个栗子?：
纯函数：
function add(a, b) { return a + b; }
非纯函数：
function now() { let now = new Date(); return now; }
函数中如果包含 Math.random，new Date(), 异步请求等内容，且影响到最终结果的返回，即为非纯函数。

3. Store
Store 数据存放的地方，store保存从进入页面开始所有Action操作生成的数据状态（state），每次Action引发的数据变更都必须生成一个新的state对象，且确保旧的state对象不被修改。这样做可以保证
应用的状态的可预测、可追溯，也方便设计Redo/Undo功能。
使用轻量级的immutable方案immutability-helper，相比完全拷贝一份（deep clone）性能更优、存储空间利用率更高。

总结：
严格遵循架构规范和单向数据流规范，可以保证我们的前端应用在比较粗的粒度上的可维护性和扩展性

 

转载于:https://www.cnblogs.com/lyls/p/7606915.html