目前是这样做的:
一个前端应用有两种数据, 远端数据, 自身数据.
远端数据一般是从服务器拉取, 也可以缓存到本地然后根据过期时间从缓存中拿. 按下不表.
对于使用 Redux 的应用, 将数据处理分为 APIs, Actions, 分别对应 远端数据, 自身数据.
两个 API:
一个 Action
实际的操作又会将这些混合在一起
一个 修改用户名 操作(可能会使用 redux-thunk):
这样做有哪些槽点? 哪些需要改进?
 |
1
xieguanglei Mar 24, 2017  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 Mar 24, 2017 1
没有什么槽点，不过推荐使用 redux-saga 来处理异步 action ，会简约很多。
可以一个操作对应一个 action ，比如说你的修改用户名 action 在 dispatch 之后，步骤 1 、 2 、 3 会集中在一个 Generator 函数处理，并且可以灵活调用其他的 Generator 函数。 最后再推荐两个可能对你有用的工具： reduxsauce 、 apisauce |
 |
5
cloud107202 Mar 24, 2017
redux-saga +1
redux-thunk 和 promise 都改变了 Action 的语义，不推荐 |
Select Language