StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Asynchronous Tasks broadly fall into 5 different problem domains.</p> <h1>Network/Local data requests</h1> <p>Probably the most common, and well covered by Fabrizio Calderan's answer. In these cases we have to handle at least 2 outcomes, and depending on granularity (various types of success or errors for a request), and then act on them.</p> <p>Deferred/Promises allows us to chain, or parallelise requests, or hybrids of both to achieve the resource loading we need for our task. For example, we can wait for a range of requests to complete before we then load some more, or do something else based on those outcomes.</p> <h1>Animation</h1> <p>Chaining/Parallel animated sequences, are more easy to implement, and maintain. Conditional steps based on different outcomes (when accounting for user interaction or a random factor.) are also easy to implement and maintain.</p> <h1>(pseudo) Modal User Interaction</h1> <p>True modal operation isn't possible in the browser, and presenting dialogs, wizards etc. requires asynchronous operations provided by Deferred/Promises to act on resolved outcomes, (success, activities, options, cancellation etc.) before cleaning up the display (also simplified, as mentioned already) and resuming normal operation. Deferred/Promises allow you to act on those outcomes in a relatively simple declarative fashion.</p> <p>Effectively this combines user interaction with animation/display sequences. </p> <h1>Hardware availability/responses</h1> <p>Mobile device(s) availability (for example through PhoneGap) needs to be guaranteed before calling them for services, and in many cases, provide response asynchronously. Using Deferred /Promises simplifies and improves the code managing these device interactions.</p> <h1>Software component activity</h1> <p>SQLLite specifically, provides it's responses to JS requests asynchronously, and so doing complex query interactions, is far simpler than it would be using callbacks.</p> <p>In theory this applies to any auxillary software component which provides asynchronous responses. </p> <h1>One more thing...</h1> <p>This is one of the best articles I've read on Deferred/Promises, I recommend reading it for some proper in-depth examples and explanations.</p> <ul> <li><a href="http://sitr.us/2012/07/31/promise-pipelines-in-javascript.html" rel="noreferrer">http://sitr.us/2012/07/31/promise-pipelines-in-javascript.html</a></li> </ul> <h1>tl;dr</h1> <p>The big benefit of Deferred/Promises is that they make solutions for several domains much easier to conceive in the first place and maintain afterwards. In some cases they simplify them so much, that had they been attempted using callbacks and convoluted outcome checking, many fully grown adults (and possibly a number of small children) </p> <h3>...would go from this...</h3> <p><img src="https://i.stack.imgur.com/wtxvf.png" alt="We're on a boat, and we're using Deferred/Promises"></p> <h3>To this...</h3> <p><img src="https://i.stack.imgur.com/9o78l.jpg" alt="callbacks are a nightmare"> </p> <p>If a solution requires chaining, waiting for the outcome of one or more processes to resolve, or any combination of these, Deferred/Promises will save you frustration and anguish, and will do the same for anyone who inherits your code.</p> <p><sup>Now go out and prove me wrong by committing horrible abuses. No, really, don't do that. Write nice clean, maintainable code.</sup></p> <p><sup>Disclaimer: Using Deferred/Promises in your code may not feel like you are "on a boat", but it will feel way better than a soup made of callbacks</sup></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload