参考
资源
关于前端项目全局状态管理库的选型(react)
纯 Hooks 的实现
react-state-patterns
hookstate
unstated-next
react-hooks-global-state
constate
比较奇怪的实现
先定义 model，再以 Hooks 的方式消费的实现
老牌的实现
GraphQL的实现
抉择
纯 hook 的实现过于简单,基本上是直接基于 react context api,基本没有模块的实现, 仅仅是单一的状态树.
而老牌的如 redux 则过于复杂, Flux 的概念其实非常不错, 而且基于此的生态十分健壮, 但样板代码又实在是太多了, 显得非常啰嗦.
所以只能在 easy-peasy overmind overstated ayanami flooks 中选一个了.
ayanami 和 overmind 其实都挺不错, 但是都有一个缺点, 引入了其他概念.
如 ayanami 就是基于 rxjs 的实现. 我想喜欢 rxjs 的团队应该会喜欢这个方案.
flooks 去中心化的确不错, 但基于字符串的 api 将会与 typescript 的类型支持进行艰难的斗争
我看了源码, 作者完全放弃了这方面的努力. 羸弱的类型支持, 将使 typescript 形同虚设.
而 overstated 如果没有 easy-peasy 我就选他了
easy-peasy 基于 redux 与 immer .
前者, 使我们能够直接拥有 redux 的繁荣生态, 而不必接纳 redux 啰嗦的样板代码.
后者, 使我们以 Mutable 的形式, 完成 Immutable 的操作.
更高的抽象, 简单的概念, 均衡.
而如果要用 GraphQL 的话, 集请求与状态管理于一身的 apollo-client 将是不二之选.