Advance your knowledge and skills of promise-based APIs, promise behaviors and patterns in JavScript. Master async control flows, composition patterns, scoping, promise-callback interop., error handling, lazy evaluation, and many other relevant topics. Use latest ES6 features and functional helpers to make your code clean, safe, and modern. After this tutorial you'll be able to twist and bend any promise-based code like a true magician!
65 exercises with solutions and explanations.
Before you start
1. We believe that a learning environment should be as realistic as possible. There are no Paste-n-Run sandboxes for coding tasks at Paqmind. You should use your own editor to write code and your own machine to run it – like a real programmer does.
2. Make sure you know the required theory, at least in the first approximation. Terms from the Curriculum should sound familiar for you. Refer to the Theory list below and always search for more. Start tomorrow (or next week) but start prepared.
3. Don't expect to pass the tutorial in one sitting. It's not a usual Easy-Level stuff made to massage your ego. We tried to make each exercise challenging, sometimes even discomfortable, yet enlightening. If you're here just to verify your knowledge, it may take a few days. But if you're new to the topic – it may easily take two weeks or more.
Refer to the How-to page for more information.
From the author
Should we follow a bad specification or teach you some better async patterns inevitable departing from a widespread standard? To give you an example, promises A+ introduce state and fate concepts:
Promises have two possible mutually exclusive fates: resolved, and unresolved.
- A promise is resolved if trying to resolve or reject it has no effect, i.e. the promise has been "locked in" to either follow another promise, or has been fulfilled or rejected.
- A promise is unresolved if it is not resolved, i.e. if trying to resolve or reject it will have an impact on the promise. A promise whose fate is resolved can be in any of the three states:
- Fulfilled, if it has been resolved to a non-promise value, or resolved to a thenable which will call any passed fulfillment handler back as soon as possible, or resolved to another promise that is fulfilled.
- Rejected, if it has been rejected directly, or resolved to a thenable which will call any passed rejection handler back as soon as possible, or resolved to another promise that is rejected.
- Pending, if it has been resolved to a thenable which will call neither handler back as soon as possible, or resolved to another promise that is pending. https://github.com/domenic/promises-unwrapping/blob/master/docs/states-and-fates.md
WTF? It can take you years to realize that all this mess really comes from the auto-flattening mechanics of A+ promises. Remove it and get 3 predictable states: "pending", "resolved", and "rejected" with absolutely no need for "fates", "settlements" and extra terms like that.
It's not a hindsight, many people were vocal about the design issues of A+. For example, you can check this historical thread. Judge for yourself.
In the upcoming Expert tutorial we'll redesign promises from scratch, so we'll have an opportunity to look at the sources and discuss engineering flaws of A+ in details. Meanwhile, we just ask you to follow the first part and judge for yourself. It's really a challenging goal to skim over controversial moments, to keep explanations simple, and to actually teach something useful and portable at the same time. Yet we believe the goal is achieved in this tutorial.
In this tutorial we deliberately decided to avoid "real" APIs like Node's FS or Browser's
Fetch in favor of "abstract"
setTimeout / setInterval-based code.
There are three decisive reasons for this.
1. The best learning model is to learn "one thing at a time". Learning an API and learning its underlying concepts are two different tasks. Learning how to combine those concepts together and apply them to solve a real-world problem is a third task.
2. Real APIs are almost always saturated with extra "noise". For example,
fetch will require you to
always apply two promise calls in a row, so you may take it as a norm (which it isn't).
FS.readFile will require you to learn buffers, to think about filesystem specifics. Again, basically,
you have to switch from the original intent of "learning some async" to learning stuff that slows
you down and may even be irrelevant (assuming so many possible JS application fields).
3. Timeouts and intervals aren't only extremely important on themselves, they are perfect as stubs for actual file, db, network, whatever "real" APIs. You'll also find them absolutely indispensable in tests, library code and many other key places. You can't overpractise them.