Flux 架构模式和 Redux 区别

核心概念对比

• Flux：
  • Flux是一种架构模式，有Dispatcher、Actions、Stores和Views四个主要部分。其核心是单向数据流，动作（Actions）通过Dispatcher分发到Stores，Stores更新数据后通知Views进行更新。例如，在一个简单的计数器应用中，点击“增加计数”按钮会触发一个增加计数的动作（Action），这个动作被Dispatcher分发到存储计数状态的Store，Store更新计数后，视图（View）显示新的计数。
• Redux：
  • Redux是一个JavaScript库，用于管理应用程序的状态。它的核心概念包括store、action和reducer。Store是一个单一的数据源，存储整个应用的状态。Action类似于Flux中的动作，是一个包含type属性和可能的其他数据的对象，用于描述发生的事件。Reducer是一个纯函数，它根据之前的状态和传入的动作来计算新的状态。例如，在同样的计数器应用中，有一个Redux store存储计数状态，点击“增加计数”按钮触发一个增加计数的action，reducer接收当前状态和这个action，返回一个新的计数状态存储在store中。

数据流对比

• Flux：
  • Flux的数据流相对来说比较灵活。它有多个Stores，每个Store可以独立处理不同类型的动作，并且Stores之间可以有一定的交互（虽然这种交互通常是被谨慎使用的）。例如，在一个包含用户信息和订单信息的电商应用中，用户信息Store和订单信息Store可以分别处理和自己相关的动作，并且在某些情况下（如用户登录后获取订单历史）可以相互通信。
• Redux：
  • Redux强调单一的数据源，即一个应用只有一个store。所有的状态都存储在这个store中，所有的action都通过reducer来更新这个store中的状态。这种方式使得数据的流动更加集中和可预测。在上述电商应用的Redux版本中，用户信息和订单信息的状态都会存储在一个store中，通过不同的reducer来分别处理和这两种信息相关的action。

组件和状态更新对比

• Flux：
  • 在Flux中，Views通常会直接订阅Stores的变化。当Stores更新后，会通知Views进行更新。每个Store可以有自己的订阅者（Views），并且可以根据需要选择合适的方式来通知Views更新。例如，一个Store可以使用事件发射器（EventEmitter）来通知订阅的Views。
• Redux：
  • Redux通过react --redux库等工具，将组件和store连接起来。组件可以通过mapStateToProps等函数从store中获取需要的数据状态，并在store状态更新时自动重新渲染。这种方式使得组件和状态的连接更加规范化。例如，一个React组件可以通过connect函数与Redux store连接，获取其中的用户信息状态，当用户信息状态在store中因为某个action被更新时，组件会自动重新渲染。

复杂度和灵活性对比

• Flux：
  • Flux相对来说更灵活，因为它允许有多个Stores，开发人员可以根据应用的具体情况来设计数据存储和处理的方式。但这种灵活性也可能导致结构的复杂性增加，特别是在大型应用中，Stores之间的交互和管理可能会变得比较复杂。
• Redux：
  • Redux提供了一种更简单、更规范化的状态管理方式。它的单一store和纯函数式的reducer使得代码结构更加清晰，易于理解和维护。不过，这种简单性在某些情况下可能会被认为是一种限制，例如对于一些非常复杂、具有高度定制化数据存储需求的应用，可能需要花费更多的精力来将所有状态整合到一个store中。

中间件对比

• Flux：
  • Flux本身没有像Redux那样内置一套成熟的中间件机制。不过，开发人员可以通过一些自定义的方式在Dispatcher等部分添加类似中间件的功能，用于处理异步操作等情况，但这种方式相对不那么标准化。
• Redux：
  • Redux有丰富的中间件支持，如redux - thunk、redux - saga等。这些中间件可以方便地用于处理异步操作，如网络请求。例如，redux - thunk允许action creator返回一个函数而不是一个简单的action对象，这个函数可以在内部执行异步操作，然后根据结果返回新的action来更新store。