Are you a compulsive reloader?

Posted July 16th, 2013 by guidone with No Comments

Several months ago I started working on Appcelerator Titanium, mainly in Javascript, the same language as the previous position but with a little difference: the IDE now takes 1-2 minutes to compile while on the web re-starting the project is just a matter of hitting the reload button.
I realized that I was compulsively hitting that button even for small changes.
When re-starting the project is a cost in terms of time – like in Titanium (consider the compilation and the time needed to navigate to the right feature) – it’s mandatory to write more code between reloads.
It turned out that now I write better code.
How many lines of code do you write on average between a reload?

JsDuck tag for Deferred methods

Posted October 12th, 2012 by guidone with No Comments

I started working with the awesome JSDuck to document my projects (do you like the doc system on Sencha Touch?) and, since I’m a great fan of Deferred object, I saw the lack of support for this kind of pattern.
Setting the @return tag with something like @return {jQuery.Deferred} is not enough since the returned value that matters is that passed through the .resolve() method of the deferred object.

Would be nice to mark a method as “deferred” and use the @return tag to document the value passed with .resolve(), keeping in mind that the actual value returned by the function is a just e promise.

Luckly JsDuck supports custom tags:

require "jsduck/meta_tag"
module JsDuck::Tag
   # Implementation of @deferred tag
   class Deferred < JsDuck::MetaTag
      def initialize
         @name = "deferred"
         @key = :deferred
         @signature = {:long => "deferred", :short => "DEF"}
         @boolean = true
      end
   end
end

Put this somewhere, for example ‘jsduck/deferred.rb’ and remember to call JsDuck with the param “–meta-tags=jsduck/deferred.rb”.

Deferred object as callback

Posted October 10th, 2012 by guidone with 6 Comments

Callbacks are a nice way of Iversion of control, but are even more powerful with deferred objects.
Basically callbacks are a way to pass back the control from a called function, the deferred/promise just do the opposite: it returns the control the called function.

Consider this scenario: a table widget, with the classic delete/modify buttons next to each row. Since the table widget is a generic component, we want to handle the delete operation on the model outside the widget, and we don’t event want to extend the generic object to do that, we want to user a callback:

$.widget('my_table_widget',{
   onDelete: function(id_of_row) {
      var that = $(this);
      // call the backend and delete the record
      $.ajax({
         method: 'delete',
         url: '/api/records/'+id_of_row
         })
         .done(function() {
            // ok, record delete, now I should update the table
            that.widget('remove_row',id_of_row);
            });
         }
      });

In the example above: the callback first calls the backend to remove the record and then removes the row from the table (I mean the DOM). In order to do this: it needs to know something about the table widget (in this case, the method “remove_row”).
But what if we could pass the ball back to the widget? Let’s rewrite it with a deferred object:

$.widget('my_table_widget',{
   onDelete: function(id_of_row) {
      var deferred = $.Deferred();
      // call the backend and delete the record
      if (confirm('Delete?')) {
         $.ajax({
            method: 'delete',
            url: '/api/records/'+id_of_row
            })
            .done(function() {
               // ok, record delete, now I should update the table
               deferred.resolve();
               })
            .fail(function() {
               deferred.reject();
               })
         }
      else {
         deferred.reject();
         } 
      return deferred.promise();
      }
   });

It’s more linear but, most important, the callback knows nothing about the remove_that_damn_row_from_the_dom method of the widget, it just passed back the control, it’s like saying “I’m done, it’s your turn”.
More separation, less documentation to read, easier to implement, less errors.

On the widget side, the callback should be treated this way

// somewhere inside the table widget, here is where we execute the callback
var callback_result = options.onDelete.call(widget,id);
// if the callback answer with a deferred/promise, this will
// handle it when it's resolved/rejected
if (isPromise(callback_result)) {
   callback_result
      .done(function() {
         // ok, asynch operation on the other side is over
         // remove the row from the dome
         widget.widget('remove_row',id);
         })
      .fail(function() {
         // do nothing
         })
   }
  • Categories

  • Tags

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2 other subscribers

  • Twitter

    Flickr Stream