Join egghead, unlock knowledge.

Want more egghead?

This lesson is for members. Join us? Get access to all 3,000+ tutorials + a community with expert developers around the world.

Unlock This Lesson
1×
Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.

Autoplay

    Inject dependencies into Epics

    Shane OsbourneShane Osbourne
    redux-observableredux-observable

    Often in unit tests we are focussing on the logic involved in crafting a network request, & how we respond to the result. The external service is unlikely to be under our control, so we need a way to ‘mock’ things like Ajax requests in a way that allows us to focus on the logic. In this lesson we’ll see how we can pass in dependencies into epics to make testing things Ajax requests easier.

    Code

    Code

    Become a Member to view code

    You must be a Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    Discuss

    Discuss

    Transcript

    Transcript

    Instructor: The current implementation of this search feature makes some assumptions about the environment in which it's running. For example, we use this AJAX getJSON from RxJS AJAX. That assumes we're in an environment where that can even be run.

    Likewise, we're using this global variable document here, which again assumes we're in an environment that has the global variable document. Using these types of things within our epics make it harder to test and harder to reuse them in other environments.

    There's a simple solution, something that comes to us from the Redux-Observable library. They allow us to give a third argument here which is an object literal of dependencies that you can define.

    We can put getJSON here. We can remove this. This now would move into where we configure the store. As the only argument to create epic middleware, we give an object literal there and a special key, dependencies. We can give any number of items here.

    The reason we do this is that now this function is much, much easier to test, because it really is just a function that takes a stream of actions, a stream of state, and an object literal, in this case with just one function on it. We can also do this for things like the document.

    We would just move that to there. This tiny abstraction allows us to sell the store based on the environment. For example, we could have these as the default dependencies. Then we could spread in something that comes in here. We could set it to an empty object.

    Right now, in our application, we only have one place that uses this ConfigureStore function. That's in the index.js, where we're actually rendering to the DOM. By removing our dependencies away from the epics and into this object here, it means that in a test scenario, we can just call ConfigureStore, and we could pass in any of these to override them.

    Let's just verify everything still works. We can still search. Nothing's changed in the application, but we've just made it far, far easier to test in the future.