Rob Griffiths wrote: > Scott Sauyet wrote: >> Rob Griffiths wrote: >>> @Scott: What about when the library also needs to inject some >>> management before the user gets given control? > >> I'm not sure I'm following what you mean here. But since the promises >> constructor implementation is presumably centralized, you could >> instrument it however you need. > > In the example of an ajax request, my library does some manipulation > of the response before handing control to the users callback, is it safe > to assume that I could do a similar thing with promises?
Certainly. Promises are a very simple concept. Instead of a caller supplying callback functions, the callee returns an object to which the caller can then attach callbacks (even after the asynchronous process has completed.) When the asynchronous process completes, the appropriate callbacks will be called with the result or the error. The change in interface is not at your AJAX level, but at the level of how processes that call for the AJAX action interact with your API. >>> Do we think that promises are not far different from an event >>> manager? If it is far different, which is best? > >> Although, as I said, the constructor is centralized, the promises >> instances are not centralized, so I don't think it would have much in >> common with an Event Manager. Can you explain why you juxtapose the >> two? > > Again in the case of an ajax request, there are only really 2 things > happening, a success and failure. These are 2 callbacks that could > be better served as 2 events perhaps? Of course any code can be factored into events in this way, but I don't see what that has to do with promises as an abstraction. Somehow in your system you need to find a way to link the callback you want to run with the result of a particular asynchronous call. You can supply a token with your event publication (or have the EventRegistration return such a token) to use for attaching your handlers, or you can supply callbacks as parameters to your API implementation of the asynchronous actions, or you can do what Promises do, and return an object from these calls which allow you to attach your callbacks as needed. A centralized event registry doesn't seem to offer any additional simplicity. 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? -- Scott -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
