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".
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.