Dean Landolt wrote:
> On Tue, Mar 29, 2011 at 1:33 PM, Scott Sauyet <[email protected]>wrote:
>> Dean Landolt wrote:
>>> On Tue, Mar 29, 2011 at 11:58 AM, Scott Sauyet <[email protected]
>>> wrote:
>
>>>> Lib:
>>>> when(/*Deferred*/ dfd): Promise
>
>>>> Deferred:
>>>> promise(): Promise
>>>> resolve(/*Whatever*/ args): void, calls 'then' listeners
>>>> reject(/*Whatever*/ args): void, calls 'fail' listeners
>
>>>> Promise:
>>>> then(/*Function*/ fn): Promise, will fire on resolve
>>>> fail(/*Function*/ fn): Promise, will fire on reject
>
>>>> [ ... ]
>
>>>> That is, I believe, a simplification of jQuery's API. Is this the
>>>> type of code you're trying to include in your library?
>
>>> Well, not quite. The fail method is redundant as the then method is
>> spec'd
>>> to take both a success and failure callback
>
>> Right, I was describing a simplification of jQuery's API, not an
>> implementation of the Promises/A, Promises/B, Promises/KISS, or
>> Promises/D proposals.
>
> jQuery's API is an implementation of Promises/A -- and it extended it a bit.
> So, one you simplify jQuery's API what you end up with *is* Promises/A
> -- the smallest possible surface area specified.
That's one possible simplification of jQuery's API. Mine is
different. Mine simplifies the API by subtracting the "failure" --
and possibly "progress" -- callbacks to ".then", by removing the
methods "done", "resolveWith", "rejectWith", "isRejected", and
"isResolved" from Deferred, and the "done", "isResolved", and
"isRejected" methods from Promise, as well as simplifying the
parameters to accept only functions, not arrays of functions. If this
is the sort of API the OP wants, it should be pretty easy to build.
But I contend that it has much the same surface area of your
simplification. It's a matter of the difference between
Promise:
then(/*Function*/ fn): Promise, will fire on resolve
fail(/*Function*/ fn): Promise, will fire on reject
and
Promise:
// will fire fn1 on resolve, fn2 or reject
then(/*Function*/ fn1, /*Function*/ fn2): Promise
Those are fairly similar APIs. The advantage of the latter is that
it's closer to the Promises/A proposal. The advantage of the former,
to my eyes, is that it's cleaner to use.
>> In the jQuery API, they did eventually add the failure callback
>> parameter to ".then()". Was the progress callback eventually added,
>> do you know? But the API works fine without it, and for a
>> simplification for someone unsure who's trying to start an
>> implementation, it seemed reasonable to include only the success
>> handler for the first pass.
>
>> Honestly, though, I prefer jQuery's "then/fail" to the single method
>> of Promises/A.
>
> I don't know if they ever added the progress callback -- I doubt it. But
> yeah, sure the API works fine without it -- that's my point. The fail method
> isn't a simplification of the API, it's a complication. Perhaps one you
> like, but it adds to the surface area. Like I said, it's redundant.
Not the way I've defined it. I understand that it's further from
Promises/A, but this seems as much anything a learning exercise for
the OP.
>> I'm less convinced by jQuery's "done".
>
> Yeah, it's pretty sloppy.
Actually, I misunderstood it. I thought it was a universal "Fire this
on success or failure". Instead it's the equivalent of
".then(handler)" without the subsequent parameters. Definitely ugly.
> [ ... ] But ugh, jQuery really made a mess of when.
In what way?
-- 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]
