Lately I’ve been playing with Ember and Backbone, and enjoying these modern tools for building modern web applications (I’ll try Angular next.) Ember and Backbone are different in many ways. While writing apps with them, I have realized that, apart from all the architectural/philosophical divergence, they employ very different approaches to event subscription, which is a critical part of any UI application.

Backbone apps depend heavily upon Backbone’s event model. The idea is simple: object A listens to object B’s event C, and gets notified whenever C is triggered on B. Ember does it differently. Instead of having one unified event model, Ember breaks the publish/subscribe pattern into Bindings, Observers, and Computed Properties, while not providing explicit event listening. The breakdown is insightful, and each has different uses. However, I’ve found cases where none of them is as helpful as the old event pub/sub pattern.

When building Sparkl, I needed to animate the interface whenever a user likes an item. Any user, not just the person in front of this interface. Therefore, I’m triggering a “getting liked” event from the model. This would be straightforward in Backbone:

1
2
3
4
5
6
7
8
9

# In model
like: ->
  # Update model
  @trigger 'liked'

# In View
initialize: ->
  @listenTo @model, 'liked', ->
    # Animate

When I tried to use Ember’s observer, however, I realized that I can only observe property updates. “Getting liked” is an event, and there is no property here to be observed! Therefore I would have to make up a variable to record the event of “getting liked”. It won’t work if the variable stores information of the user liking it, because if a user likes the item, unlikes it, and likes it again, this variable won’t update at the second like, and the observer won’t fire. So I decided to track the time when the item gets liked, and observe this property from view:

1
2
3
4
5
6
7
8
9

# In model
like: ->
  # Update model
  @set 'latestLikeDate', Date.now()

# In view
animateLike: ( ->
  # Animate
).observes 'controller.model.latestLikeDate'

Not very complex code, but a little tricky. Another downside is that extraneous properties are introduced to the model, and needs to be filtered out when sending model to server. So while Ember provides new approaches to address common problems, perhaps traditional solutions are still good to have.

Update: Ember.Evented

I discovered that Ember has an Evented mixin, which supports similar event pub/sub as in Backbone. Now I’m using this:

1
2
3
4
5
6
7
8
9

# In model
like: ->
  # Update model
  @trigger 'isLiked'

# In view
init: ->
  @get('controller.model').on 'isLiked', ->
    # Animate

Much better.