fix(store.dispatch): Calling store.dispatch() directly in your Epic is now deprecated

[jayphelps]

This is unrelated to usage of store.dispatch inside your UI components or anywhere outside of redux-observable--you will continue to use it there

The ability to call store.dispatch() inside your Epics was originally provided as an escape hatch, to be used rarely, if ever. Unfortunately in practice we've seen a large number of people using it extensively; there has even been popular tutorials teaching it as how you use redux-observable. This is ultimately my fault as providing this ability first-class made it seem like it was sanctioned. Instead, Epics should emit actions through the Observable the Epic returns, using idiomatic RxJS. If you're looking for the ability to directly call dispatch yourself (rather than emit through streams) take a look at some of the other middleware available in the community. 🥇

Before

const somethingEpic = (action$, store) =>
  action$.ofType(SOMETHING)
    .switchMap(() =>
      ajax('/something')
        .do(() => store.dispatch({ type: SOMETHING_ELSE }))
        .map(response => ({ type: SUCCESS, response }))
    );

After

const somethingEpic = action$ =>
  action$.ofType(SOMETHING)
    .switchMap(() =>
      ajax('/something')
        .mergeMap(response => Observable.of(
          { type: SOMETHING_ELSE },
          { type: SUCCESS, response }
        ))
    );

store.dispatch will be removed from Epics in v1.0.0 of redux-observable alongside the removal of store.getState() but replaced with a observable of state$ that also has state$.value if want to just access the current value.

Cc/ @evertbouw

[jayphelps]

This is so that when process.env.NODE_ENV === 'production' we don't import the console.js file at all since it's not needed.

[rgbkrk]

I like this pattern.

[rgbkrk]

Thanks for making it back off after being logged at least once.

[rgbkrk]

I like how this goes from handy escape hatch to anti-pattern.

[jayphelps]

Ok once the build passes we're good to go.

[jayphelps]

Thanks for the review @rgbkrk!!

[adred]

I'm new to rxjs. So does this mean I won't be able to call action creators anymore? It sucks because instead of reusing action creators I now have to type the actions. :-(

[jayphelps]

@adred fear not! you can ABSOLUTELY use action creators. This only deprecated using the store.dispatch function inside epics, that’s it.

[adred]

@jayphelps yeah, that's what I meant. I'm using dispatch(actionCreator) inside my epics.

[jayphelps]

@adred gotcha, different terminology.

It’s very anti redux-observable and was never intended to be used except for hacks—which a person can still do, they can inject the store themselves, or export and import it, etc. I recommend against it though, as this is fighting the redux-observable way. There’s no harm in not liking it, there are lots of middleware to choose from or you can roll your own. 🖖

[rgbkrk]

If you need to dispatch in the middle of your epic, there are many ways to do it. By the nature of the epic you need to emit actions anyways. You can merge together multiple streams of actions for example using mergeMap:

import { of } from "rxjs/observable/of";
import { empty } from "rxjs/observable/empty";
import { mergeMap } from "rxjs/operators";

action$.ofType("SOME_TYPE").pipe(
  mergeMap(action => {
    // within merge map you return an observable of actions
    // and they become the next part of the stream
    if(...) {
      // You can return one
      return of(someAction);
    } else if (...) {
      // or many
      return of(someAction, anotherAction);
    } else {
      // or nothing
      return empty();
    }
   // or even whole new streams composed of various things
  })
)

How you approach it depends on what kind of control flow you want.

[trubi]

Guys, quick question.
Sometimes I am using this (with native module):

const magtekModule = NativeModules.MagtekManager
const eventEmitter = new NativeEventEmitter(magtekModule)

eventEmitter.addListener(
    "MagtekManagerEventDataReady",
    (payload) => dispatch({
            type: MAGTEK_MANAGER_DATA_READY,
            payload: {
                magstripe: payload[0],
        }
    }))

Or what else should I use if I need to dispatch action from outside of my redux app? Some kind of middleware? Could you point me somewhere? Thanks!

[jayphelps]

@trubi happy to help if you wanna ask it on StackOverflow so the knowledge is shared.

[trubi]

Great idea indeed thanks! https://stackoverflow.com/questions/47665255/alternative-to-direct-calling-of-store-dispatch

[ecnaidar]

So the getState() will still be available as a parameter, right? Removing dispatch is a sane move to make people do thing Rx way, but removing ability to access state might make some things unnecessarily complicated.
I will leave what I have came up with here just in case. No idea if that is a 100% correct way of dispatching in the middle of epic. (Not really experienced with RxJS but worked for a while with redux-saga)

action$
    .ofType(CREATE)
    .flatMap(action => {
      // Save our request observable so we can process output two different ways
      const request$ = Observable.fromPromise(requestCreate(action.payload));
      return [
        // Before API request 
        Observable.of(startSubmit("template")),
        // 1. Notify that load is done
        request$.map(response => {
          console.log("stopping submit");
          return stopSubmit("template", response.error || {});
        }),
        // 2. Format and emit result
        request$
          .map(response => {
            console.log("returning response");
            console.log(response);
            if (!response.errors) {
              return saveTemplate(response.data);
            } else {
              return undefined;
            }
          })
          .filter(v => v)
      ];
      // Each element produces plain redux action
    })
    .concatAll();