Deferred objects VS backbone events for View updates in Marionette

Question

I am learning Marionette / Backbone with the excellent book "Backbone.Marionette.js: A Gentle Introduction". In the chapter 'Handling Data Latency', the Author (David Sulc) uses JQuery deferreds objects / promises to pass data from the fetch() action (called in entities/contact.js) to controllers (show_controller.js and list_controller.js in the example).

Code is available here : https://github.com/davidsulc/marionette-gentle-introduction/commit/de25497a1fa028f6a4471b0003645307a6e426f8

I understand how it works but in my previous readings on Backbone, this kind of thing was handled by Backbone events: we listen to a 'change' event on the model and we call render() when it is triggered. So I have a few questions about that :

1/ Are deferred objets better than backbone events for updating the view when we get a response from the server?
2/ What are the pros and the cons of the 2 solutions?
3/ Is it wrong / bad design to use backbone events in this situation?

Thanks for your help!

Answer 1

A specific use-case would be where you want to load/instantiate a view only when a model/collection has been fetched from the server. In that case you can use the Deferred object because that'll tell you exactly when the data has been loaded.

Of course you can listen to a change event on the model/collection, but you'd need to have a view instantiated already or add an extra listener to your model/collection to create the view.

So, to answer your questions:
1. Really depends, if you don't mind updating your view, then events are fine. If you want to instantiate a view later on, deferreds are a good fit.

2. See introduction

3. Not really. It also depends on the scale of your application. As S_I_R mentiones as well, it'll probably result in a bit cleaner code.

Answer 2

Ok, let me try explaining,

1. Deferred Objects have promises so it contains callback built right in it. So in data driven web application its better to use this to get rid of callback hell for asynchronous functions.

2. If you need to bind a user control event then you need trigger or events from Backbone.Events to do that, in that case you have to manually propagate your event through the controllers. On the other hand deferred objects can give status when it is finished, so after that you can populate your view or do other task.

3. Well deferred mechanism was introduced to ease up situation where manual callbacks are overwhelming. It is much easier to use promises instead callback which makes code cleaner. And as javascript being single threaded promises are more efficient for async operation.

Answer 3

1) Are deferred objects better than backbone events for updating the view when we get a response from the server?

Deferred objects are better.

I'll explain why. Relying on the view to re-render after the change or sync event on its model or collection can lead to visual anomalies. Lets take an example when you fetch a collection from a server and display its models as a list. When the collection has zero models you want to display 'No models found'. In this case before the collection is fetched and a 'change' event is fired, the user will see 'No models found' on the screen. As soon as the collection is fetched the view will re-render itself and now the user will see the models. This can lead to confusion. Although this is just one of the many use cases I am sure you get my point.

Once your object has been fetched from the server you can then bind the view's render() method to the object's 'change' or 'sync' event for any subsequent changes that may happen to the object.

2) What are the pros and the cons of the 2 solutions?

I think the answer to question 1 answers this question as well.

3) Is it wrong / bad design to use backbone events in this situation?

Probably. I would go with S_I_R's answer on this one.