On Tuesday, 1 November 2011 at 13:09, Scott Sauyet wrote:
> 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.
Because they both execute a function at some time in the future. This may be
the wrong way to be thinking about Promises.
> But I wouldn't add one only for taming asynchronous
> calls. That is what Promises do well.
Having heard your arguments for them over the complexity and overhead of an
event manager, I completely agree.
> 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.
Yes I hadn't thought about the fact there maybe several asynchronous ajax calls
happening at one. (dumb I know cause its asynchronous)
> > 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.
Thinking you've warmed me to the idea, kudos.
> > 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.
Finally an example and I understand it :)
> (I'm sure that untested code is buggy, but it should show the idea.)
I get the idea.
> > So which promise spec should we follow? and which promise
> > libraries are worth looking at?
>
> If you're looking at implementing your own, look at
> as many of them as you can.
I've looked at several and they all vary, but now I understand the concept I
can reassess them.
--
Rob Griffiths
Twitter: @bytespider
Github: https://github.com/bytespider
bytespider.eu (http://bytespider.eu)Sent with Sparrow
(http://www.sparrowmailapp.com/?sig)
--
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]
