Динамика и иммутабельный flow

Спасибо, за урок! Да, весьма интересный вопрос, только тайп скрипт может дать соблюдение строгости написания кода и крутые подсказки в шторме, но с другой стороны, возрастет сложность проекта и восприятие кода будет малость усложнено, тоже интересно по какому пути пойдет Дмитрий.

Добавил в планы по доработке. Спасибо!

Частично решено: в коммитах проекта на Github есть изменения :)

Просто в JS код выполняется не один раз. У JS-движка есть так называемый Event Loop. Это бесконечный цикл, запускающих выполнение кода из очереди итерациями (тиками):

while(queue.waitForMessage()){
  queue.processNextMessage()
}

Простой синхронный скрипт выполняется весь в первом тике и очередь опустошается.

Но из нашего скрипта мы можем закинуть туда в очередь на будущее (как будто в фон) любой свой коллбэк через process.nextTick:

process.nextTick(function () {
  ...
});

и он выполнится в следующей итерации. Туда же в очередь закидываются все события из окна браузера вроде наших кликов.

Например, туда мы можем поместить проверку готовности чего-нибудь. И если готово, то выполнить onSuccess. А если ещё нет, то повторно подписаться на следующий тик:

function check(onSuccess) => {
  process.nextTick(() => {
    const ready = ...
    if (ready) {
      onSuccess()
    } else {
      check(onSuccess);
    }
  }
}

check(() => { console.log('Ready') })

console.log('Started')

В итоге у нас выведется Started, а check просто закинет коллбэк в очередь для следующей итерации Event Loop. И когда-нибудь потом в одной из итераций сработает if, вызовется onSuccess и выведется Ready.

И так закидывая некоторые фрагменты кода в nextTick можно делать код, в котором выполнение фрагментов будет чередоваться. Это и есть асинхронность. Примерно так и работают все асинхронные операции. Они просто вбрасывают свой код с коллбэком в следующий тик. И когда-нибудь в каком-нибудь тике этот код переданный коллбэк вызовет.

А промис - это просто объект-контейнер, в котором хранятся наши три функции и статус c результатом. В конструктор передаётся наш основной код executor с любым асинхронным кодом, а потом в then и catch передаются коллбэки, которые он вызовет потом в случае успеха или ошибки.

И если бы мы сами писали Promise, то в более простом виде могли написать его с приёмом всех трёх функций в конструктор:

class Promise {
  constructor(executor, onSuccess, onError) {
    function resolve(result) {
       process.nextTick(() => onSuccess(result))
    }
    function reject(error) {
       process.nextTick(() => onError(error))
    }
    try {
      executor(resolve, reject)
    } catch (error) {
        reject(error)
    }
  })
}

И использовали бы его как:

new Promise(
  (resolve, reject) => { console.log('A'); resolve('B') },
  (result) => { console.log(result) },
  (error) => { console.log(error) }
)
console.log('C')

И это бы вывело результат как с настоящим промисом:

A
C
B

Мы у себя в промисе поместили вызов onSuccess в nextTick. Но реальный Event Loop сложнее и этапов там несколько. В нативном промисе в JS коллбэки из then и catch выполняются не в следующем тике, а на этапе микрозадач после текущего тика.

Таким образом промис - это обёртка, помогающая записывать асинхронный код с коллбэками в более удобном виде.

А в вашем примере не сам промис разблокирует поток, а просто его не блокирует асинхронная функция loadPicture. В каком-то тике она увидит, что файл до конца догружен и вызовет resolve, который дёрнет displayPicture. Если же loadPicture будет синхронной, то она выполнится сразу и промис ей никак не поможет.