Enter Your Email Address to Watch This Lesson

Your link to unlock this lesson will be sent to this email address.

Unlock this lesson and all 832 of the free egghead.io lessons, plus get RxJS content delivered directly to your inbox!



Existing egghead members will not see this. Sign in.

Just one more step!

Check your inbox for an email from us and click link to unlock your lesson.



Introducing run() and driver functions

4:06 RxJS lesson by

The last part of the code we wrote is neither logic nor effects. It is code which ties together logic (main) with effects. We can encapsulate that in a run() function. This lesson shows how we can structure these pieces together, and generalize effect handling with "drivers".

Get the Code Now
click to level up

egghead.io comment guidelines

Avatar
egghead.io

The last part of the code we wrote is neither logic nor effects. It is code which ties together logic (main) with effects. We can encapsulate that in a run() function. This lesson shows how we can structure these pieces together, and generalize effect handling with "drivers".

Avatar
Samuel Sharpe

If you comment out Log: from main(), it will still throw an error. I think run() would need to check the keys before running each effects https://jsbin.com/fahazihahe/1/edit?html,js,console,output?

Avatar
Andre

Samuel, correct! That if statement slipped from me when recording, and the program still executed. However, we quickly introduced the official Cycle.run(), which I mentioned has enough error checks. The point of this lesson is to understand what run() is responsible for.

In reply to Samuel Sharpe
Avatar
BigAB

So close to calling it Log Driver
https://www.youtube.com/watch?v=upsZZ2s3xv8
...so close

Our application now has some clear structure. We have main for logic, and we have some effects functions, but this part down here is neither logic nor effects. What it does is tie together the main with the effects. Essentially, it is meant to make our app just run.

We can extract that and put it in a function called run, which takes the main function as an argument, and it will just run this piece of code. Now we need to call run giving the main and our app runs.

Let's say I want to instead not have this log effect happening any more. For some reason, I just don't think it's important for our app anymore, but because the effects are hard coded in the run, this will be undefined. We don't have log anymore, so then if you look at the consoleLogEffect function, we're going to be attempting to subscribe to something undefined, which is an error.

The problems are that in the first place we are hard coding these effects inside run. Instead, we should be able to specify that these are the effects that I want to run my main function, so we need to give our effects to run as well.

That will be an object. Effects functions will be an object, and the keys will match those keys that we saw from the sync here. The DOM function is DOM Effect, and the log function is consoleLogEffect.

Now that this object and that function is given to run, we need to tie together these things, so what we can do is we can get all the keys of the effects object. We can iterate over them, get each key, and if we do effects and get the member key, this is now...for instance, if the key is DOM, then this is the DOM Effect function.

We need to run that effect function against the sync of the corresponding sync. If the key is DOM, then the syncs.DOM is that observable, so now we're running these effects against their corresponding syncs. We can see the consoleLogEffect is happening and the DOM Effect is happening.

If we want, we could just say we don't actually want to have this consoleLogEffect anymore, and then we only have the DOM Effect. This is how run becomes very generic, and we don't need to hardcode anything inside it anymore.

One last space we're going to add to this is that effects functions don't really sound like something nice. I'm going to call this instead drivers. The reason why I call it drivers is because we can take some inspiration from operating systems.

A driver is an interface between software, your computer programs, and hardware. If we think that our "hardware" here, in quotes, is effects, then our drivers are interfaces, things, between our program and effects. That's why I'm going to call this a DOM Driver, and the consoleLogEffect, I can call it just consoleLogDriver, and these are now drivers.

This is just to give a better name for our concepts.

HEY, QUICK QUESTION!
Joel's Head
Why are we asking?