Vuex & SSR
-
关于状态管理的一点思考
-
Vuex 核心原理与使用
-
SSR 到底怎么回事
##关于状态管理的一点思考
前端发展到今天,更主流的模式 UI = f(state)
,视图通过底层框架(vue/react 等提供的能力)根据状态进行驱动。
对前端工程师而言,挑战变成了如何更好的去定义、更新。储存、共享这些状态,因为状态在某一时刻的快照与视图一一对应,且非常具有函数式编程范儿
状态管理是当前前端最核心的部分,因为视图能用状态描述,所以前端的逻辑复杂度转移到了如何让状态"不要出错",前端与后端的一个区别在于,状态在前端是长生命周期的,又会在这个生命周期中有不可枚举地、未知的、难以追踪的多次修改,保证其按照既定轨迹不出错就很困难了
状态是一直变化的
最广义程度来看,状态本质上还是一种可以描述视图状态、行为的数据结构,状态的管理则是通过一定的算法将这些数据结构组织、管理起来,
程序 = 算法 + 数据结构
状态大致可分为两类:本地状态 和 共享状态
本地状态就是 vue 中的data,react中的 state ,这里我们一般会用来控制弹窗的显示与隐藏、loading效果等。
共享状态其实是最头疼的问题,但是有时最常见的场景,业务中肯定会出现大量需要兄弟节点通信。祖孙节点通信等的场景,通信的目的是为了状态分享,虽然可以通过一些方式,比如回调函数等手段实现,但都不是最佳实践
项目复杂度和组件层次结构的复杂性是衡量是否使用状态管理工具的标准
面临的问题
状态管理的方式:中心化和去中心话两种模式
Dan 曾经说过 SPA 应用的最佳实践十分位容器组件和展示组件,通过 props 向下传递,这样分层之后的好处显而易见,只需要维护好容器组件内部的状态就行,展示组件和业务组件逻辑解耦,但是真的是这样吗?分析公司内的项目代码,大家可能会发现,经常出现层级嵌套5-6层的页面,这样传下去谁也不敢保证中间环节不出现什么问题,还是做不到单一,解耦。
所以 flux 架构及其追随者 redux vuex被提出,主要思想是**应用的状态被集中存放到一个仓库中,但是仓库中的状态不能内直接修改, 必须通过规定的方式 才能更新状态
这样,当我们完全控制了状态的改变,我们可以很容易的追踪状态的变化,也让应用开发更容易调试。开发工具可以检查状态的变化。
但是这种模式下写出的代码很冗余,有大量模板代码
状态划分
状态划分的粒度可大可小,react社区最新的状态管理工具 recoll
从原子粒度 atom来划分