How an extremely simple implementation of a Promise works

Question

I'm reading through this article on the inner workings of a promise. To do that, the author showcases a simplified implementation of a promise working properly.

The code is as follows:

class PromiseSimple {
  constructor(executionFunction) {
    this.promiseChain = [];
    this.handleError = () => {};

    this.onResolve = this.onResolve.bind(this);
    this.onReject = this.onReject.bind(this);

    executionFunction(this.onResolve, this.onReject);
  }

  then(onResolve) {
    this.promiseChain.push(onResolve);

    return this;
  }

  catch(handleError) {
    this.handleError = handleError;

    return this;
  }

  onResolve(value) {
    let storedValue = value;

    try {
      this.promiseChain.forEach((nextFunction) => {
         storedValue = nextFunction(storedValue);
      });
    } catch (error) {
      this.promiseChain = [];

      this.onReject(error);
    }
  }

  onReject(error) {
    this.handleError(error);
  }
}

And it is called as such, just like a regular promise:

// Assume this is your AJAX library. Almost all newer
// ones return a Promise Object
const makeApiCall = () => {
  return new PromiseSimple((resolve, reject) => {
    // Use a timeout to simulate the network delay waiting for the response.
    // This is THE reason you use a promise. It waits for the API to respond
    // and after received, it executes code in the `then()` blocks in order.
    // If it executed is immediately, there would be no data.
    setTimeout(() => {
      const apiResponse = fakeApiBackend();

      if (apiResponse.statusCode >= 400) {
        reject(apiResponse);
      } else {
        resolve(apiResponse.data);
      }
    }, 5000);
  });
};

I'm having a hard time grasping the following:

1. Why do lines 6 and 7 of the PromiseSimple class exist? I'm trying to understand the point of binding this.onResolve to this. Isn't it already bound to the proper this context?

2. I don't understand why this implementation doesn't block the main thread. No where in the PromiseSimple class does it offload the work onto another thread or anything of the sort. But surely enough, if I put a console.log(...) statement at the very end of my program, that console.log(...) statement would be printed out as the first thing I'd expect it to, like a regular promise. I figured it'd be paused until the fake makeApiCall function had finished since this isn't a true implementation of a promise.

I want to grasp this but I'm just not getting how this mini implementation allows the proper promise behavior that we're used to. Any help is greatly appreciated.

---

Update

A recommendation of making this a duplicate has been proposed but I want to elaborate why they are not the same. The duplicate question is more high level theory of why async calls are needed. I understand their use, and importance, and the various ways they're implemented. I'm looking to understand under-the-hood how they work.

Answer 1

1. onResolve and onReject have to be bound in order to prevent the executionFunction to apply them with another context or without any context. (if for whatever reason you call resolve or reject with another context, it has to be bound to PromiseSimple, otherwize this will refer to something else or won't refer to anything if no context).

Here is an example that won't work if you don't bind onResolve or onReject :

const makeApiCall = () => {
    return new PromiseSimple((resolve, reject) => {
        Promise.resolve().then(resolve); // Using native promise here : resolve is called without context and won't work if not bound
    });
}

2. This implementation does block the main thread but you won't probably see it since you're using a setTimeout which delays the execution in the event loop. The true Promise implementation delays the tasks you define in then or catch callback as microtask in the event loop. (There is this very interresting article about browsers event loop).

Hope this helps,

Answer 2

regarding 1, let's look at a standalone example

execute = func  => func()
class X {
    xfunc() {return this;}
}
let x = new X();
execute(x.xfunc) // undefined
execute(x.xfunc.bind(x)) // x
execute(x.xfunc.bind(5)) // 5

in general, when you refer to a function, such as x.xfunc it loses it's this context. This isn't usually a problem, because you usually don't invoke object functions like this, but rather call x.xfunc() directly. Same goes to all objects, not just objects created with the class and new syntax.

let x = {xfunc: function() {return this}}
x.xfunc() // x
execute(x.xfunc) // window
execute(x.xfunc.bind(x)) // x

Now, with arrow functions, it's a bit different

An arrow function expression has a shorter syntax than a function expression and does not have its own this, arguments, super, or new.target MDN

let x = {xfunc: () => this}
x.xfunc() // window
execute(x.xfunc) // window
execute(x.xfunc.bind(x)) // window

Regarding 2, it's essentially just callbacks. Consider the below example

let callback = () => { console.log('callback') }
let promise = { resolve: () => { callback() } }
console.log('this is not blocking');

Now, it should be obvious that nothing is blocking, e.g. the console log is printed even though we never resolved the promise via promise.resolve(). Promises r really just syntactical sugar for the above with some extra logic for chaining.