从Redux Observable返回一个Promise

dpa*_*lus 3 rxjs redux redux-observable

也许我正在考虑这个错误,但是我使用redux-thunk的一个常见模式是返回一个promise,这样当一些事情完成或失败时我可以在容器对象中执行一些额外的操作.


以Thunk为例:

动作创作者:

const action = ({ data }) => (dispatch) => 
    fetch(`some http url`)
    .then(response => {
        if(response.ok) {
             return response.json();
        }

        return Promise.reject(response);
    })
Run Code Online (Sandbox Code Playgroud)

连接组件中的某个位置:

this.props.action("Some Data")
    .then(console.log)
    .catch(error => console.error("ERROR"));
Run Code Online (Sandbox Code Playgroud)

在Redux-Observable/Rxjs中有一种干净的方法吗?基本上从一个动作返回一个promise,调用一个epic,一旦observable完成就返回解析或拒绝.

jay*_*lps 6

一般来说,当我使用像redux-observable/redux-saga这样的东西时,我会试图让人们远离这些模式.相反,如果您正在等待您调度以更新商店状态的操作,请依赖于状态更新本身或您的Reducer存储在其中的状态的某种事务元数据.例如{ transactions: { "123": { isPending: true, error: null } }

但是,如果你确实想要这样做,你可以编写(或使用一个现有的)中间件来返回一个Promise,dispatch这个中间件会在调度其他一些指定的动作时解析(大概是你的史诗).redux-wait-for-action就是一个例子(不是推荐,但因为我还没有使用过)

请记住,Promise通常不会被取消,因此您可能会意外地创建一个组件开始等待操作的情况,用户离开该页面并卸载组件,并且您仍在等待其他操作 - 以后可能会引起奇怪,比如他们回到那个页面等等.


如果你正在等待链接副作用,那就属于你的史诗.启动史诗侦听的单个动作,产生副作用,然后发出另一个动作来表示完成.另一个史诗听取完成动作,然后开始另一个副作用等.如果你愿意,你可以将它们全部放在一个单片史诗中,但我发现分离更容易进行测试和重用.

  • 每句话都没有规则,但这听起来像是史诗中的逻辑。除了维护私有内部状态的通用组件外,其他组件不应包含此类业务逻辑。他们呈现DOM,并响应UI事件调度动作,然后根据商店的状态及其道具进行重新呈现。 (2认同)