总结自己使用过的Hooks数据流方式 #88
zhangyu1818
announced in
zh-cn
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hooks
正式推出也有一年出头了,总结这一年中,自己使用过的Hooks
数据流方式目前接触过的数据流方案大致是2种方式
React
的数据流React
的数据流基于React的数据流实现
简单讲来,就是使用官方提供的
Hooks
,比如最常见的useState
,这种方式也是我们用的最多的useState
通过
useState
能将曾经类组件的state
值拆分为多个使用
useState
最大的好处是简洁明了,个人觉得有2个缺点useState
后不好管理state
值过于复杂,在改变值时的合并是比较难处理的针对这两个小问题,也有另一个
hooks
解决useReducer
useReducer
可以说是官方简版redux
与
redux
还有一些小差异的就是react
提倡将初始值赋值在useReudcer
的参数中,而不是reducer
的state
上面2种方式在单组件或者是父子层级组件使用还是比较方便,如果想像
redux
一样不关乎层级共享数据呢?在Hooks
中也提供了对应的方法useContext + useReducer
这种方式是我在这一年中使用最多的跨组件共享状态的方式了
这种方式能将自己的
hooks
跨组件共享状态了,使用还是比较方便,唯一的缺点就是自己需要使用createContext
来创建Context
并且挂载Provider
,会多一点步骤,也需要自己管理Context
,这可以说是纯手动unstated-next
unstated-next
是一个200 字节的状态管理解决方案unstated-next
的实现使用的全是React
的api
,源码也短,下面会对他的源码进行分析使用
unstated-next
让我们不需要自己创建和管理Context
了,从纯手动切换到了半自动UmiJS中提供的useModel
UmiJS中提供了一个
useModel
方法,可以很方便的将hooks
全局使用,它的默认规则是src/models
下导出的hooks
会作用于全局useModel
等于是省去了上面的useContext
和挂载<Prvoider>
的步骤,由框架处理了,在React Developer Tools可以看到最外层是有一个存了导出hooks
的值的Provider
的,我想他的实现方式应该和unstated-next
类似从自己创建和管理
Context
,挂载Provider
,到自己挂载Provder
,再到只需要写hooks
逻辑,过程就是手动——半自动——全自动它的缺点就是范围局限了,仅限于
UmiJS
框架基于React的数据流优缺点
仅在使用过程中个人的总结
优点
React
,没有额外的学习过程,简单易用缺点
Context无法做到精确刷新
数据是一个整体,不能做到精确刷新,一旦改变
React
就会自动触发刷新如果在
<Foo>
中调用了dispatch()
对state.foo
进行了更改,<Bar>
也会刷新不基于React的数据流实现
不基于
React
的数据流实现就是数据存储不在React
里,数据改变不会直接触发组件刷新,而是通过其他的方式触发组件重新渲染,我只使用过2种Redux
+React-Redux
DvaJs
React-Redux
在
Hooks
推出后,React-Redux
也更新了Hooks
方法,使用useSelector()
来取得state
它的优点是会精确刷新,不会像
Context
一样导致整体刷新,因为useSelector
的重新渲染是自己控制的,而不是交给React
处理Redux
+React-Redux
的缺点我想用过的都知道,就是需要管理很多文件DvaJS
DvaJS
其实没有提供Hooks
的数据流方式,云谦大佬可能全身心投入UmiJS
开发,已经有一段时间没更新了,但是我觉得作为一个集成度非常高的优秀数据流管理。仅仅使用过2个月的我对
DvaJS
的总结优点
redux-sage
解决异步数据流问题redux
+react-redux
简单很多,不再会有文件管理问题reducer
,让一些数据可以懒加载小小的总结
在类组件时代,无法拆分
state
,类组件感觉就很重,组件级state
多了也很难管理,Context
流行度也不算高,使用<Context.Consumer>
让组件更重了,后来有了contextType
也没有useContext
这么简洁,所以感觉之前流行Redux
也是有原因的,因为React
本身没有提供好的状态管理Hooks
时代,一切都变得更简洁,官方提供了useReducer
这样的简洁版Redux
,同时组件级的state
也更简单,使用自定义的Hooks
,让数据和视图耦合更低了,useContext
+useReducer
的方案可以解决大部分需要共享状态的场景使用了挺久的
React
,我感觉很多场景都不会全局共享状态,我现在做的项目就是后台管理系统,页面的数据也不会和别的页面关联,我都使用Context
一把梭了,所以我更喜欢轻量级的Hooks
数据流解决方案看看unstated-next源码
有时候感觉自己真的变成了搬运工,缺乏自己的想法,就很呆,上面提到,我很长一段时间都是用
useContext
来共享状态,每次都是手动挡,前几天突然想,为什么自己要做重复的工作,一搜果然有大佬已经写好了源码很简单,就是一个闭包
作者说 “我相信 React 在状态管理方面已经非常出色”、“我希望社区放弃像 Redux 这样的状态管理库,并找到使用 React 内置工具链的更好方法”,我觉得很有道理
参考文章:[精读《React Hooks 数据流》](
Beta Was this translation helpful? Give feedback.
All reactions