As you can see, a dom/* HTML element receives a map of properties: #js {...} or nil for no properties. This is all a bit awkward. No designer will ever be happy with this. And that's where sablono can help you turn the code into this:

Ah, much better! Each HTML element is represented by a keyword at the beginning of a vector. Then, an optional map defines its attributes. Everything else must evaluate to another HTML element, and so on. All attributes match ClojureScript's default naming conventions and are automatically converted to the camel-cased version on rendering.

To get started with sablono you just need to include its namespace and macro:

A new instance of Google Closure's History is created, and a new event listener calls secretary's dispatch! function with the current history state (the event's token field) for each of its navigation events.

Note: Since the setEnabled method fires an event for the current location immediately, it has to come after the event listener.

The only place where the user can navigate to different URLs is the footer component:

We can see that there are three possible routing states: all, active and completed. For each state there is a hyperlink in the footer that triggers the corresponding route. Nothing more to it!

By the way, the original Om application from the last posts already included secretary. Compiled to JavaScript it was 192 KB (47 KB gzipped) but without any routing it shrinks to 172 KB (40 KB gzipped).

om-tools

Prismatic is a very early adopter of Om and with om-tools they provide a collection of utilities to help eliminate a few annoyances and add extra functionality. To get started you need to include the namespace:

Another big feature is the integration of Prismatic's schema library which allows declarative data description and validation. I could write an entire blog post about it but luckily Prismatic already did. So I'll just highlight how this works in our little TodoMVC application. First, we need to include the schema library:

Unfortunately, when I tried this it didn't work. I haven't found out the reason for this yet but it may be because the component is created via build-all. Not sure. But the om-tools example actually works, so go on over there to see it in action.

Anyway, to get what we came here for: let's validate the schema explicitly.

This means we can catch errors earlier and prevent some of those subtle bugs we all know and love from dynamic languages. All the improvements come at a price, though: the resulting JavaScript code adds up to 264 KB (61 KB gzipped) now.

There are a few other things the library brings to the table - like mixins - so make sure to look into the documentation.

That's it for today. You have seen how a few libraries can help you get even more value out of Om.