两种状态管理模型

更新日期: 2020-10-23阅读: 1.5k标签: 状态

今天闲着没事,重构了 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


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

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

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

理解 React 轻量状态管理库 Unstated

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

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

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

为什么要使用状态管理

我们平时开发的大部分项目,由于复杂度不够, 很少使用 Vuex、Redux 等状态管理库,就算引入了 Vuex 这些库,也只是当作一个全局数据引用,并非对应用状态进行管理。但一旦页面的复杂度比较高,必然要引入状态管理,今天就聊聊我理解中的状态管理。

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

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

如何使用react hooks来进行状态管理?

首先要明确为什么要使用redux,这一点很重要,如果不知道为什么使用redux,那么在开发的过程中肯定不能合理的使用redux.首先来看redux的本质:redux做为一款状态管理工具,主要是为了解决组件间通信的问题。

Flutter基础--状态管理

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

共享可变状态中出现的问题以及如何避免?

本文回答了以下问题:么是共享可变状态?为什么会出现问题?如何避免其问题?标有(高级)的部分会更深入,如果你想更快地阅读本文,可以跳过。

使用Observable实现Vue全局状态共享

项目不大, 又不想用Vuex, 那么使用Observable来实现状态共享也不失为一个选择。用法 :让一个对象可响应。Vue 内部会用它来处理 data 函数返回的对象

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

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

点击更多...

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