我们在用，目前遇到的问题是：页面节点太多的情况下，每次状态变更都比较卡。
比如：一个长列表，有一个下拉选择筛选条件 type，如果列表已经加载了 20 条，setType('xxx') 时就会卡一秒甚至更多

我觉得是因为他是基于 react 的，需要维护一个 dom 树，每次 react 状态变更要先 diif 一下，然后发送到小程序又要 diff 一下，这个通信比较慢。
和 wepy 这种直接编译成小程序代码不同，状态就是小程序自己管理了。

不过还好，reamx 允许嵌入小程序原生组件，UI 频繁切换状态我们用原生写了
可以原生只写切换部分，渲染还是用的 remax 。
就好像 web 上面，频繁 setState 会比较卡，那就获取 domRef 手动设置 style 。写法稍微有一点点麻烦就是了

@darknoll 忘记加狗头了

@letking 比较同意。
我觉得后端们学习一个新的领域要摆正心态，

“前端这么简单，我应该看两眼就学会了嘛。这个写的这么 low，肯定是前端全都这么写” 这种心态不要有。

你觉得是奇葩的写法那就去找更优的写法，又不是没有。

你需要一个状态管理插件，以前我用 redux mobx 。
react 16 推出 hooks 后我使用 https://github.com/jamiebuilds/unstated-next/blob/master/README-zh-cn.md

readme 的指南部分，有介绍这个库的设计思路，就是用简单封装一下 react 的 context api

不过直觉上这种性能没多大差别吧，写法麻烦了。你可以先测试一下看看。

因为参数变化才需要重新定义，那利用一下 event 对象吧。

const handleClick= (e)=>{
const item = category.find(x=>x.id ===e.target.dataset.id)；
}

category.map(item=>{
return (<div data-id={item.id} onClick={handleClick} />)
})

@byte10 经典 你觉得不好 是你不够“高级”。

@byte10 经典把 mac 硬件和 win 软件混为一谈。。。

确实，没买 mac 电脑的，没用 4k 的都该 kill 掉。

@919615766 是的，发布就一直在用。你看 readme 可以知道这个库就是对 react context api 的简单封装，没有多少更新维护的需求了。

代码也就 40 行，真有啥问题 fork 一下自己改

redux 算是第一代状态管理了吧，这个真不行，开始我宁愿挂到 window 里我都不愿用这个。
第二代是 mobx，这个集中管理，用了一段时间，就是使用还要注入，缺少类型提示，勉强用着。
第三代 react16 推出了 hook，就有了这个 https://www.npmjs.com/package/unstated-next 。可以说已经完美了。

没有 TS ？？没有 TS ？？没有 TS ？？

@zhengfan2016 可以设置成中文。。