第一次分派后 redux-observable 的多个动作

Question

我是此处描述的“registerEpic”实用程序：Is it an efficient practice to add new epics lazily inside react-router onEnter hooks?

我们的代码需要是等量的，但是在服务器端，第一次触发一个动作，一切都很好。但是第二次触发该动作时，史诗似乎获得了该动作的 2 个副本。这是我的代码：

export const fetchEpic = (action$, store) =>
  action$.ofType("FETCH")
    .do((action) => console.log('doing fetch', action.payload))
    .mergeMap(({meta:{type}, payload:[url, options = {}]}) => {

            let defaultHeaders = {
                'Accept': 'application/json',
                'Content-Type': 'application/json'
            };

            options.headers = {...defaultHeaders, ...options.headers};

            let request = {
                url,
                method: 'GET',
                responseType: 'json',
                ...options
            };

            //AjaxObservables are cancellable... that's why we use them instead of fetch.  Promises can't be cancelled.

            return AjaxObservable.create(request)
                .takeUntil(action$.ofType(`${type}_CANCEL`))

                .map(({response: payload}) => ({type, payload}))
                .catch(({xhr:{response: payload}}) => (Observable.of({type, payload, error: true})));

        }
    );

 registerEpic(fetchEpic);

所以我第一次点击触发此操作的页面（服务器端）一切正常，我在控制台中得到了一次“正在执行获取”。

但是，刷新页面会产生 2 条控制台消息，并且不会触发所产生的操作。

我在我的史诗注册表中添加了一个“清除”功能，但也许我完全是菜鸟，只是没有完全理解它。这是我的中间件：

let epicRegistry = [];
let mw = null;
let epic$ = null;
export const registerEpic = (epic) => {
    // don't add an epic that is already registered/running
    if (epicRegistry.indexOf(epic) === -1) {
        epicRegistry.push(epic);

        if (epic$ !== null) { //this prevents the observable from being used before the store is created.
            epic$.next(epic);
        }
    }
};

export const unregisterEpic =(epic) => {
    const index = epicRegistry.indexOf(epic);
    if(index >= 0) {
        epicRegistry.splice(index, 1);
    }
}

export const clear = () => {
    epic$.complete();
    epic$ = new BehaviorSubject(combineEpics(...epicRegistry));

}

export default () => {

    if (mw === null) {
        epic$ = new BehaviorSubject(combineEpics(...epicRegistry));
        const rootEpic = (action$, store) =>
            epic$.mergeMap(epic => epic(action$, store));

        mw = createEpicMiddleware(rootEpic);
    }

    return mw;
};

Answer 1

我在任何地方都没有看到epicMiddleware.replaceEpic？如果你不替换中间件中当前运行的史诗，真的很难保证它没有采取行动——这听起来和这里发生的完全一样。

使用 redux-observable（或任何异步中间件，包括 redux-saga）进行服务器端渲染非常困难，因为您必须创建一些约定。例如当您的应用程序启动时，如果史诗开始产生一些副作用，您什么时候说“这就够了”并过早地将其切断？你让他们做任何异步的事情吗？你如何正确地保证史诗真正结束它的所有副作用？中间件可能停止订阅史诗，但它没有正确链接其订阅者，因此无论如何都会继续产生一些副作用。

这就是为什么我们还没有记录如何在 redux-observable 中执行 SSR，因为虽然我们已经创建了“执行它”的代码，但我们对选择没有信心。

无论您决定如何处理它，您很可能希望最终调用 epicMiddleware.replaceEpic(nextRootEpic) 以使中间件停止订阅之前的根史诗。

如果您不想让史诗在服务器端页面渲染期间完全异步执行任何事情，您将同步渲染页面，然后在再次用相同的根史诗替换根史诗之后立即.也就是说，你几乎肯定会再次传递完全相同的根史诗，这将有效地“重新启动”你的史诗树——但同样，如果你写了一个行为不端的史诗，也不能保证。

如果您想发布您的实际 SSR 代码，我很乐意帮助您进一步详细说明，例如如果你使用 React 和 react-router，那将是你所有的 match({ routes, location: req.url } ...etc) 东西。

---

值得注意的是，很多人都有SSR should not do any side effects的意见，并把它们留给客户。所以没有 AJAX 调用，在像 React 这样的 redux-observable 情况下，这意味着在 componentDidMount （不是在服务器端运行）之前不要调度会导致副作用的操作。这主要是因为在许多方面这会破坏 SSR 可能带来的性能优势，因为您没有尽快发送初始 HTML，而让 JS 出现。但是，通常没有提到的是，如果您不提取任何类型的动态数据，您的应用显然不会有那么多的 SEO 好处。这是一个你必须决定的权衡，或者可能同时使用两者。