[jpfuentes2]

Thanks for clearing up the confusion. Although, I think it's worth it for you to edit your initial reply since it's the most upvoted comment so far.

Also, your comment, to me, shows there is still some confusion regarding Om's internals:

> However, this relies on being able to listen for state change from the underlying model data. [...] Instead, it seems that with Om, you are limited to consuming data structures that implement its state change notification interface.

Actually, the interface used is ClojureScript's flavor of STM: you set your app state, generally a hash-map, in an atom. When you mutate the app state via `swap!` it is published to Om -> React -> render. This may seem like a pedantic distinction, however, the key point is that you are required to use an atom which controls app state mutation. You could also use strings and vectors as your app state if you so choose.

[Touche]

Interfacing with an external js library that publishes changes would be trivial though. Typically if you're building a ClojureScript app you're building a ClojureScript app... which means using atoms.