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 1046 of the free egghead.io lessons, plus get RxJS content delivered directly to your inbox!

Existing egghead members will not see this. Sign in.

From toy DOM Driver to real DOM Driver

4:52 RxJS lesson by

This lessons shows how we are able to easily swap our toy DOM Driver with the actual Cycle.js DOM Driver, a more solid, more flexible, more efficient implementation.

Get the Code Now
click to level up

egghead.io comment guidelines


This lessons shows how we are able to easily swap our toy DOM Driver with the actual Cycle.js DOM Driver, a more solid, more flexible, more efficient implementation.


Hyperscript normally enables the style attribute to be either a string or an object, while it seems the implementation from CycleDOM that was demonstrated in this video only accepts an object.

Is there a particular reason by design for this deviation?

In reply to egghead.io

Hi Kevin. No particular reason. I haven't yet seen anyone wanting to write the style as a string. In any case, I recommend writing styles in CSS or some JS solution that compiles to CSS.

In reply to Kevin

Now we have our own DSL here for creating views in the main. What comes next? How can we improve other code around it even further? Could we make this toy DOM Driver be just the library that we can import and use in other applications?

Yes, we can do that but it has a problem for reusability. This ID app is hard coded in the DOM driver to refer to the container element where the app lives. Other applications would need to use this magical ID app when created an element on the HTML.

Instead, it would be better if we could just specify this ID as a parameter somehow. What we can do, is make a function that returns a DOM Driver. Given this mount selector, we can actually return functions in JavaScript. Functions are just first class citizens, so let's return a function.

Let's return a DOM Driver and this DOM Driver will use the mount selector that we just specified. Then to use this driver, we need to create it first. We create the DOM Driver using this ID app and this will return to us the DOM Driver function to repass. Here's the run and it works. Our DOM Driver, this toy DOM Driver still has plenty of problems.

One of the serious problems here is that we are clearing the container element every time we receive a new description object. In fact, if this object is a really large tree that we would create here, then we would be like flushing the DOM and recreating it at every tick or it could be much worse. This is a really bad idea for performance.

The second problem is that here for select events, we are using the tag name and we don't support things such as like rich selectors with class names and etc. and IDs. Sometimes it would be better instead of saying like, "I want all of the mouse hovers any span in the application, I was mouse hovers only on spans that have class fu or even just elements that have the class fu, so we would like to support this kind of API as well.

It's time for us to get rid of our toy DOM Driver and we can say bye-bye to it by replacing it with an actual cycle JS DOM Driver by importing it as a script here in the HTML. Once we do that, we get an object in the JavaScript, the global object called Cycle-DOM. This contains some things here, some helpers. It contains H, which is almost the same as this one, but it's much more advanced. It also contained H1 and span and it also contains H4 and input and LI and DIV, all these elements that we need when writing HTML.

It also has Make DOM Driver so we don't need H1 in span anymore and this H1 will work, and we can delete our toy DOM Driver and now this Make DOM Driver is coming from the Cycle-DOM, and there's yet one last thing that we need to change. Instead of calling select events in the official DOM Driver, we have select fu and then events mouse over. This here was span and if I hover here, it works.

The Cycle-DOM Driver is much more powerful than the toy driver we wrote because it doesn't have the unnecessary flushing of the DOM here. It actually uses the virtual DOM underneath to avoid really expensive recreations of the DOM tree. These things here are actually virtual DOM elements. When I said description objects, this is really the same idea as a virtual DOM element.

It's just an object saying what should happen on the DOM. Then the DOM Driver picks that up, uses the virtual DOM to do a different patch and applies those mutations to the actual DOM. Of course, the Cycle-DOM has a bunch of other nice things such as you cannot only specify children as an argument but you can also specify attribute like, let's say, style.

Here, we can give, let's say, background color, red, and then we can do that so we're starting to get a hang of how we can build full blown applications and we went from toy cycle JS to actual real cycle JS now.

Joel's Head
Why are we asking?