目前是这样做的:
一个前端应用有两种数据, 远端数据, 自身数据.
远端数据一般是从服务器拉取, 也可以缓存到本地然后根据过期时间从缓存中拿. 按下不表.
对于使用 Redux 的应用, 将数据处理分为 APIs, Actions, 分别对应 远端数据, 自身数据.
两个 API:
一个 Action
实际的操作又会将这些混合在一起
一个 修改用户名 操作(可能会使用 redux-thunk):
这样做有哪些槽点? 哪些需要改进?
1
xieguanglei 2017-03-24 12:08:20 +08:00 1
1. redux-thunk 太老了,写起来太麻烦,推荐 redux-promise ,配合 async await 大大简化代码。
2. 修改用户名的 post 请求直接返回修改后的用户信息, reducer 在修改用户名成功的 action 中单独更新那个用户。 |
2
iugo OP @xieguanglei 实际工作中, API 数据的变动会比例子中复杂, 比如批量根据用户 ID 修改用户某一属性或者链式操作. 如果每一种对数据进行修改的 API 都要创建相关 Actions 就麻烦一些, 所以目前统一逻辑就是从 API 更新.
|
3
iugo OP 有时觉得 PouchDB 是一种挺合适的做法.
|
4
Mikewu 2017-03-24 13:22:14 +08:00 1
没有什么槽点,不过推荐使用 redux-saga 来处理异步 action ,会简约很多。
可以一个操作对应一个 action ,比如说你的修改用户名 action 在 dispatch 之后,步骤 1 、 2 、 3 会集中在一个 Generator 函数处理,并且可以灵活调用其他的 Generator 函数。 最后再推荐两个可能对你有用的工具: reduxsauce 、 apisauce |
5
cloud107202 2017-03-24 14:24:56 +08:00
redux-saga +1
redux-thunk 和 promise 都改变了 Action 的语义,不推荐 |