Our application was able to produce write effects, through sinks, and was able to receive read effects, through the DOM sources. However, the main function only gets the DOMSource as input. This lessons shows how we can generalize main to receive an object of sources, containing all kinds of read effects that we can use.
[00:00] Our application is able to produce write effects through the syncs and is able to receive read effects through the sources. Symmetrically drivers will receive write instructions and will perform those write instructions and then they will return sources in order to provide the read effects.
[00:37] We left the run hard coded and messy, so let's fix that. What we did for the domDriver only we can do also for all of the drivers provided here in the argument.
[00:50] First we need to create syncs for all of the drivers, not just this driver. We can make that as an object here, fake syncs is an object. Then we can iterate over all of the drivers. For each key we will create that fake sync for that key. It is from extreme create. This part accomplishes for all of the drivers what this part did only for the DOM sync.
[01:22] Let's do this part, which is basically calling the functions, calling all of the driver functions. Let's bring this code back. We don't need to check for the syncs keys because we're now doing it for fake syncs. Here instead of syncs we're going to apply that for fake syncs.
[01:45] Now each of these drivers may return a source, so we can also collect those sources. Let's put that in object. We're going to say sources key is the return value of that driver. This code accomplished that part.
[02:02] Now we can also accomplish this part. We just need to call main now providing sources for all of the drivers, not just the DOM one. We accomplished that. Now we just need to accomplish this part as well. We can iterate over all of the syncs, and then we can call imitate. Fake syncs key should imitate the syncs key. Then we accomplish this part. Now this should work like before.
[02:43] As you can see we have the console effect and the DOM effect, so we can delete the hard code that we wrote. Our toy cycle.js is almost done. In fact we could take this run function and extract it and put it in a library.
[03:00] Why not import the real cycle.run at this point? This is something we can do right now actually. We can import that script for cycle.run. It's a package. Then we can use that instead of using our own hard coded version here. We can just say cycle.run. It still behaves like we expect it to, having those two effects in place.
[03:27] Basically cycle.run is not scary, it's almost the same thing that we had before except it has more error checking and covers more corner cases, so overall it's more reliable.
Up to this lesson I had been working with
rxjs5, but I don't know the
cycle.js ecosystem well enough to discover the right import to factor in
https://cdnjs.cloudflare.com/ajax/libs/cyclejs-core/7.0.0/cycle.js, but that did not work.
Can you correct my reference? I wish to continue the lessons with rxjs5.
Hi Will. In this course we've been using RxJS version 4. In the JSBin you can see from the HTML tab which JS resources we are using, for instance
https://cdnjs.cloudflare.com/ajax/libs/cyclejs-core/6.0.3/cycle.js. We should update the course material to reflect the latest versions.
Here's a snippet working with RxJS 5: http://jsbin.com/voxereq/7/edit?js,console,output