关闭

两种状态管理模型

时间: 2020-10-23阅读: 97标签: 状态

今天闲着没事,重构了 doux,内心一阵唏嘘,在这个状态管理烂大街的年代,谁能想到,曾经的我也搞过状态管理呢,接下来我认真谈一谈


鼻祖 elm

doux 的前身是 smox,也是一种 elm 的 js 替代实现,elm 首次将状态与视图概括为一个著名的等式: UI = state + effect

这个等式牛逼就牛逼在,它可以概括 90% 的场景,它主要有两点:

1.全局 state 树 
2. effect 隔离

redux 是 elm 的一个实现,它使用 reducer 去同步处理 state,使用中间件机制去实现 effect

dva 也是一个 elm 的替代实现,它使用 saga 去处理 effect...

还有 vuex,rematch,甚至我写的 smox

那个年代,大家对乐此不疲的讨论状态管理,纷纷给出不同的实现,甚至状态管理一度称为新人的处女作品没有之一


react 是另一个模型

elm 的模型是好的,我们乐意花时间去理解和研究这个模型,但是将 elm 的模型用于 react 就不太靠谱了……react 其实是另外一个模型: UI = fn(state)

这里的 fn 一般指的是 setState,或者说是组件也可以,反正这不是重点

重点是这里的 state 是局部的,每个组件都有自己的 state,react 自带一套基于组件和局部 state 的状态管理

强行将 elm 的模型套用到 react 中,是很怪异的

很久很久以后我才发现,原来两套不同的状态管理模型,很难强行套用在一起

这里不合理不是来自于这两个模型本身,而在于不同的人对两个模型的理解存在偏差,

有的人认为 elm 的模型是好的,所以项目就全部用 redux

有的人认为 react 的模型不好,就提倡不要在 react 中用 setState,比如 mobx 作者……

最终大家谁也说服不了谁,害


我提倡只使用 react 的模型

随着 hooks 的出现,组合更灵活,useContext 的使用方式也变得超级简单,所以在 react 里共享 state 已经不再是难事

context 就是简单的发布订阅,有人要说 context 会导致重复渲染,性能不好,不够精确

所以我重写了一下 doux,它使用依赖收集来 精确更新

import { observer, observable } from 'doux'
import { render } from 'react-dom'

const data = observable({ count: 0 })

const App = observer(() => (
  <div>
    <div>{data.count}</div>
    <button onClick={() => data.count++}>+</button>
  </div>
))

上面这段代码,首先 data 是全局的,然后首次渲染,根据 data.count 进行依赖收集,当 data.count 发生变化的时候,依赖它的组件就 rerender

context 就是简单的发布订阅,其实依赖收集也是发布订阅,只不过发布的时候有映射关系

无敌完美,只有俩 API,就解决了问题

大家可以看到,这个 API 长得很像 vue3 的 composition API,我们借机谈一下


composition API 的缺陷

我一直认为 composition API 不是个好东西

最大的坑是 reactive 和 ref,其实这个坑本质上是因为他们要将 data 作为局部的,然后 return 给 template 导致的

但是使用闭包进行依赖收集的机制,根本不 care 你这个 data 是局部的还是全局的

昨天写了一天 vue3,写一个嵌套表单就把自己绕进去了,toRefs 什么的,心智负担太大了

所以今天才会重写 doux,拒绝抄袭不好的东西呜呜呜


write on copy

为了保证不可变,doux 使用了类似 immer 的写时拷贝机制,不过 doux 的做法更纯粹,写的时候拷贝,取的时候先从拷贝中取

唉,用 Proxy 模拟 document,依赖收集,写时拷贝……感觉 Proxy 快被我玩坏了 emm


总结

大家在 fre 中可以使用 doux,因为 fre 没有 context,在 react 中能用 context 还是用 context

除非你真的对 doux 很感兴趣,哈哈,放一下 github 地址,欢迎 star 和 pr!

https:// github.com/yisar/doux


站长推荐

1.云服务推荐: 国内主流云服务商,各类云产品的最新活动,优惠券领取。地址:阿里云腾讯云华为云

2.广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入

链接: http://www.fly63.com/article/detial/9802

关闭

你再也不用使用 Redux、Mobx、Flux 等状态管理了

这个库的作者希望使用 React 内置 API ,直接实现状态管理的功能。看完这个库的说明后,没有想到代码可以这个玩。短短几行代码,仅仅使用 React Hooks ,就实现了状态管理的功能。

理解 React 轻量状态管理库 Unstated

在React写应用的时候,难免遇到跨组件通信的问题。现在已经有很多的解决方案。React本身的Context,Redux结合React-redux,Mobx结合mobx-react

node如何实现保持登录状态?

当我们登录成功,在这个页面刷新,页面并没有保存登录状态;今天我们就来看一下如何在后台使用cookie保存用户登录状态。做到刷新页面仍然显示在用户登录界面。node实现保持登录状态的方法如下:

React 状态管理的 3 个规则

React 组件内部的状态是在渲染过程之间保持不变的封装数据。 useState() 是 React hook,负责管理功能组件内部的状态。我喜欢 useState() ,它确实使状态处理变得非常容易。但是我经常遇到类似的问题:

Flutter基础--状态管理

当我们使用编译器创建一个新Flutter应用的时候,我们可以在主界面看到两个小部件StatelessWidget和StatefulWidget。这是两个最常见使用最频繁的小部件了。StatelessWidget ,StatefulWidget

React使用Hooks与Context替代Redux状态管理

React Hooks 在 2018 年年底就已经公布了,正式发布是在 2019 年 5 月,关于它到底能做什么用,并不在本文的探讨范围之内,本文旨在摸索,如何基于 Hooks 以及 Context,实现多组件的状态共享,完成一个精简版的 Redux。

3条简单的React状态管规则

React组件内部的状态是在渲染之间保持不变的封装数据。useState()是React钩子,负责管理功能组件内部的状态。我喜欢useState()确实使状态处理变得非常容易。但是我经常遇到类似的问题:

Javascript 状态管理工具 DataSet ,实现数据的订阅、查询、撤销和恢复

网页是用户与网站对接的入口,当我们允许用户在网页上进行一些频繁的操作时,对用户而言,误删、误操作是一件令人抓狂的事情,“如果时光可以倒流,这一切可以重来……”。

provide/inject实现状态管理

这对选项需要一起使用,以允许一个祖先组件向其所有子孙后代注入一个依赖,不论组件层次有多深,并在起上下游关系成立的时间里始终生效。如果你熟悉 React,这与 React 的上下文特性很相似。

Angular 状态管理方案调研

RxJs + Service 组件内管理状态:在组件中可以声明一个属性,作为组件的内存存储。每次操作时调用服务(service)中的方法,然后手动更新状态。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!