不太理解类似于redux-thunk这样的中间件对于发送异步action有什么意义,
不可以在异步回调之后直接手动dispatch一个action吗?
不太理解类似于redux-thunk这样的中间件对于发送异步action有什么意义,
不可以在异步回调之后直接手动dispatch一个action吗?
当你异步回调一个action
时,如果不依赖这个异步返回的数据时,没有问题。当要依赖返回的数据时就出问题了。
因为接口还没返回,这个dispatch
就已经发出了。
所以在redux-thunk
中,使用一个promise
来对异步的处理。
你可以参考一下rudex-saga
或者dva
,都对异步做了很好的处理。
难道你以为thunk就不是异步回调之后手动dispatch一个action了么,最后修改store那个dispatch还不是要你自己写。
thunk做的只是让你的异步函数能够以一种方便的形式拿到dispatch和store里的state而已,并没有做很多事情,你看看源码就是知道了。
1 回答1.7k 阅读✓ 已解决
4 回答1.7k 阅读✓ 已解决
2 回答2.5k 阅读✓ 已解决
1 回答2.6k 阅读✓ 已解决
2 回答1.6k 阅读✓ 已解决
4 回答1.4k 阅读
1 回答1.6k 阅读✓ 已解决
首先,我不知道你入和对意义的定义?性能变好?代码可读性增加?扩展性变强?
If you’re not sure whether you need it, you probably don’t.
如果你处于这个阶段,你可以选择不用,官方描述。
你觉的你当前代码写的很舒服,那么为什么需要额外的引入你不了解的东西呢?当然不需要
想要知道thunk有没有意义?可以先从文档上了解
这是thunk的motivation
Redux Thunk middleware allows you to write action creators that return a function instead of an action
就是你可以dispatch(function)。
下来谈谈你的问题,不可以在异步回调之后直接手动dispatch一个action吗?
当然可以。你在异步回调之后直接dispatch,这可以啊,我觉的没什么不好。
这里主要看你对action的定义,就以网络请求为例,列个简单比较。
这种情况下,你将你xxxAction定义为一个通过数据来修改store数据的action
这种情况下,你将这个getXxxDataAction定义为一个从后台获取数据变修改store库中的Action
其实你会发现这两个写法基本是一致的,上面那种方法是没有问题的。上面的方法可以看做是下面方法的解耦。解除了请求和修改store之间的关系。所以根本没有什么非得用谁,只是你当前的场景适合用谁。
下面方法的好处是什么,就是比如我在这个系统中,我的请求和修改数据的关系是恒定不变的,那么我不解耦的用法可能会更加的舒服。比如
A 需要获取xxx数据,并存入store中。
B 也需要获取xxx数据,并存入store中。
下面这种只需要在两个组件中去添加这句store.dispatch(getXxxDataAction())
而上面那种就必须把请求以及回调来重复写一遍,同样的代码两个路口,一旦涉及到需要修改的时候,就很容易会遗漏