在第一次分派(dispatch)后 redux-observable 多个 Action

Question

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

我们的代码需要是等量的，但是在服务器端，第一次触发一个 Action ，一切都很好。但是第二次触发该 Action 时，史诗似乎获得了该 Action 的 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 好处。这是您必须决定的权衡，或者可能同时使用两者。