Observabbles are, in many ways, similar to Promises. The rule here is that we always return the core object of RxJS: Observable.
In this case, we use switchMap to ensure the any pre-existing occurrences of the operation are cancelled to make way for the new. They can safely ignore an action if it does not pertain to it.
Unlike Reducers however, Epics do not need to have an exit case defined. Similarly the call above with rootEpic is doing the same thing. Using combineReducers we can mash all of these reducers into one giant one. You recall that, in Redux, every action is passed to every reducer which is why every reducer must have an exist case. Essentially, our call above which passed in rootEpic allowed Redux to pass emitted actions into our Epics. What is happening here is actually straightforward, however the methods of RxJS can make things a bbit hard to understand at first.
Here is an example of the epic I use to get a list of Todo items from my sample application: That being said, I do not look at epics as devices for updating state in most cases, instead I look at them as more specialized aspects of the system. I like to think of epics as “Observable aware Reducers” mainly because they sit at the same level and have a similar flow. For reference, here is a look at the Redux flow with these Epics included. The parameter to this call is a listing of our “epics”.Īn epic is a new concept that redux-observable introduces. We use this new method to apply the result of createEpicMiddleware which comes from the redux-observable package. In this case, we have brought in the applyMiddleware method from redux. It is not at all unusual for this method, as your application grows in size and complexity to gain complexity as well. Here is a shot of the updated configureStore method Most of the setup work for the custom middleware happens in the configureStore method which we created during the Redux portion of this series. We need to change the middleware to support other types being returned for this we need custom middleware, which we get from the redux-observable NPM package. See, Redux expects an actual object to be returned from a reducer which is fine for state changes, but not realistic for async operations.
REDUX OBSERVABLE UPDATE
The first step in this process is to update Redux to support this approach.
REDUX OBSERVABLE CODE
I cannot say that Redux Observables are the best, but certainly I have finding more and more uses for Reactive approaches in the code I am writing so, I welcome the ability to use RxJS in Redux. Sagas, Thunks, and other approaches have been made to solve this problem. The uni-directional flow works well for this, but where it falls flat is when it comes to asynchronous operations, namely calls to get and manipulate data from a backend server. One of the great things about Redux is how well it organizes your state and how easy it can be to follow state changes.
REDUX OBSERVABLE SERIES
Today I will conclude this series as we dive into the final bit of our example and feature the setup of one of my favorite ways to structure my data access layer.
0 kommentar(er)
