Rob Griffiths wrote:
> Scott Sauyet wrote:
>> There are plenty of good reasons to create an event registry,
>> especially for larger systems, but I use them alongside Promises, and
>> never think twice about the Promises API. Can you suggest any reason
>> to switch from Promises to a registry?
>
> At the moment I understand very little about the benefits of promises,
> but I do understand about the event model. I'm thinking about
> implementing one or the other in my library so I need to understand
> the pros and cons of each approach.
I'm still not sure why you think of these as competing APIs. If you
have need in your library for an Event Registry, then by all means
include one. But I wouldn't add one only for taming asynchronous
calls. That is what Promises do well. If you have decided on an
Event Registry, you might decide to forgo Promises as the Event
mechanism does provide an alternative. But you will need to consider
carefully how easily it provides the same facilities as a Promises API
would. If you want to be able to do something like
var promise = makeAjaxCall(/* params here */);
promise.then(someSuccessHandler, someFailureHandler);
promise.then(anAdditionalSuccessHandler);
promise.then(stillOneMoreSuccessHandler, anotherFailureHandler);
then you have to think about how you'd do that with your Event
Registry. It's not that this isn't possible, but when I've done Event
Registries, they've always involved simple publish and subscribe
functions with only topic names tying them together. To do the above
with that, you'd also need a mechanism to dynamically create unique
topic names, and might also need a cache of completed events in case
someone wants to attach a handler after the fact. It's messy.
> I need to weigh up what overhead and complexity there will be, or if
> indeed a simple callback would be best.
It depends, of course, on what you want to do. But as simple promises
are very easy to implement. These days, I would always choose them
over the plain callback mechanism.
> I can see clearly that for multiple callbacks, or callbacks that require the
> presence of multiple conditions promises are extremely handy.
They have one other real advantage. `when` functions can be written
to accept either promises or other values, and to run their functions
immediately if the parameter is not a promise, or on the resolution of
the promise if one is supplied. This means you can write code that
functions identically calling synchronous and asynchronous functions.
This is to me a huge benefit.
For instance, using jQuery's Deferreds (completely untested):
var checkValidation = function(fields) {
var dfd = new jQuery.Deferred();
var i, len, promises = map(fields, function(field) {
return field.validate();
});
when(promises).done(function() {
for (i = 0, len = arguments.length; i < len; i++) {
if (!arguments[i]) {
dfd.resove(false);
}
}
dfd.resolve(true);
}).fail(function(error) {
dfd.reject(error);
});
return dfd.promise();
};
This function returns a promise, based on the results of the
validate() calls of a collection of fields. The promise will resolve
to true or false, or reject if there is some error. The field
validations can be synchronous calls that return a boolean or
asynchronous ones that themselves return promises to resolve to
booleans. Note that the code does not have to distinguish between
those fields that return booleans and those that return promises.
This is one of the benefits to most of the Promises implementations.
(I'm sure that untested code is buggy, but it should show the idea.)
> So which promise spec should we follow? and which promise
> libraries are worth looking at?
If you're looking at using one intact, jQuery's is probably only worth
considering if you're already using jQuery. Including jQuery just for
the Promises is far too heavy-weight. One of the stand-alone ones
would have to do. If you're looking at implementing your own, look at
as many of them as you can.
> when.js (https://github.com/briancavalier/when.js) and jQuery's deferred
> (http://api.jquery.com/category/deferred-object/) seem like two good
> approaches, both of which follow the CommonJS Promises/A spec.
I haven't used when.js, so I can't speak to its quality, but I like
the API it offers. If you were writing your own, I would add one bit
of syntactic sugar from jQuery's implementation to when.js's API,
though. The `done` and `fail` functions are to me more intuitive than
the single `then` function.
-- Scott
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
