目录
- 1，MVC
- 2，前端MVC的困难
- 3，Flux
- 4，Redux
1，MVC
是一个解决方案，用于降低 UI 和数据关联的复杂度。
在早期前后端未做分离时，服务端会响应一个完整的HTML，包含页面需要的所有数据。而浏览器仅承担渲染页面的作用，整体流程也就是服务端渲染。
其中服务端的处理流程：处理请求，并将需要的数据嵌入到 HTML，再返回给浏览器。
为了降低这个过程的复杂度，出现了 MVC 模式。
- 服务端收到不同的请求，分发给不同的 Controller（控制器）来处理，并组装这次请求需要的数据。
- Model 层会将数据组装为，用于UI渲染的数据模型。
- View 层会将数据模型组装到 HTML 中，返回给浏览器。
前后端分离的部分原因，
MVC 模式中，将数据模型为组装到 View 视图层生成最终的 HTML，这一步越来越复杂了。
所以想直接给前端返回数据，组装数据进行展示的逻辑，交给前端来做。
2，前端MVC的困难
前端框架 Vue、React 解决了数据 --> 视图的问题，但 Controller 比服务端复杂的多。
1，前端的 Controller 实际上是在处理用户的操作，而操作场景是复杂的，改变数据的情况太多了。
1，不同的组件有不同的操作和响应，每一个事件处理程序做的事情也都不一样。
2，比如，服务器只需要知道是否调用了某个接口，并控制器来处理逻辑。
而前端触发调用接口的场景可能不止一个：点击按钮触发，计时器触发，或其他逻辑执行完后再触发。
2，前端框架使用的是单向数据流，在共享数据时，只能将数据提升到顶层组件，并逐层传递，比较繁琐。
所以产生了上下文（React.createContext / prvide/inject）来提供共享数据。但还是有一些缺陷，尤其对中大型应用来说。
- 上下文更多应用在局部的、层级关系较深的组件间通信，并且是为了数据传递，很少有更改传递数据的情况。
- Vuex、Redux 是为了提供了更完整的状态管理解决方案，也包括时间旅行（调试，状态回溯）、模块化等。
3，Flux
FaceBook 提出的数据解决方案，最大的历史意义是引入了 action 概念。
action是一个对象，用于描述要做的事情，是触发数据变化的唯一原因。store表示数据仓库（全局单例模式），存储共享数据。会根据不同的action更改仓库的中的数据。
// 示例
cosnt loginAction = {type: "login",payload: {loginId:"admin",loginPwd:"123123"}
}const deleteAction = {type: "delete",payload: 1 // 用户id为1
}
4，Redux
在 Flex 基础上引入了 reducer，用于根据 action 来处理数据，处理后的数据会被仓库重新保存。
和 vuex 的对比：
| Redux | Vuex |
|---|---|
| Store | Store |
| Reducer | Mutation |
| Action | Action |
流程差不多相当于：
store.dispatch({type: 'ADD_TODO',count: 2,
})// action 也可以是一个函数
store.dispatch(addAction(2))
function addAction(count) {return {type: 'ADD_TODO',count,};
}function todoReducer(state, action) {switch (action.type) {case 'ADD_TODO':return Object.assign({}, state, {count: action.count + 1,});default:return state;}
}
Vuex
const store = createStore({state: {count: 0},mutations: {increment (state, { amount }) {state.count += amount}},actions: {increment ({ commit }, payload) {// 触发 mutationcommit('increment', payload)}}
})// 分发 action
store.dispatch('increment', {amount: 10
})// 以对象形式分发
store.dispatch({type: 'increment',amount: 10
})
以上。
