Реализуем собственный Promise в JavaScript

[yarkov]

У нас есть собственная реализация Promise, которая повторяет базовую модель работы нативных промисов

Осталось понять для чего нам это и будет счастье ))

[polwen]

:)

Это описание реализации, чтобы разобраться как устроен промис через попытку создать его поведение. В таком виде он еще сыроват для использования.

[Beholder]

теперь поведение соответствует нативному Promise

Это довольно сомнительно, так как нативные микротаски обрабатываются раньше нативных промисов. Получилась разве что "игрушечная" имитация для учебных целей. Вряд ли можно написать полноценную замену по спецификации если нет нативной поддержки.

[polwen]

Согласен с вами.
Я пишу в статье не полноценную замену нативного Promise, а скорее воспроизвожу его модель поведения. Цель была скорее разобраться и показать, как именно работает промис через попытку его повторить.

[Alexandroppolus]

 нативные микротаски обрабатываются раньше нативных промисов

Не совсем понял этот поинт. Вот здесь будет вывод 0 1 2, и в ноде, и в браузере:

queueMicrotask(() => console.log(0))
Promise.resolve().then(() => console.log(1));
queueMicrotask(() => console.log(2))

второй queueMicrotask не вылез вперед then

[InveterateCoder]

Потому что Промисы тоже микротаски)

[alexchizik]

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

[InveterateCoder]

Это скорее некорректно. Нативные промисы и есть микротаски, и написать свои промисы вполне возможно используя queueMicrotask(), и делается довольно часто, если поискать cancelable promises, в npm репе.

[Alexandroppolus]

Проверку instanceof MyPromise (точнее, проверку на thenable, о чем упоминается в конце статьи) так же надо делать в конструкторе промиса, в функции resolve

[polwen]

Спасибо, что обратили на это внимание.

Я упростил этот момент и обрабатываю thenable только в then , что не смешивать. Главное было найти баланс между тем, чтобы было похоже на нативный промис и при этом не переусложнить описание.

[Alexandroppolus]

Я упростил этот момент и обрабатываю thenable только в then , что не смешивать

Ну тут вы радикально упростили ) Значением промиса не может быть другой промис (thenable), это ключевой момент, оно резолвится "до упора".

Логику resolve даже надо не добавить, а перенести в конструктор, тогда она не понадобится внутри then

[polwen]

Согласен. Спасибо, что подсветили этот момент. Потому что мне бы не хотелось, чтобы были грубые нарушения. Переписывать реализацию - это наверное чересчур. Поэтому добавил в текст оговорку на эту тему.

[winkyBrain]

Подход "написать своё, чтобы понять, как работает уже существующее" - очень классный и рабочий! Когда учился, на одном из курсов по React на ютубе, прежде чем переходить к использованию Redux(само собой после объяснений, для чего вообще нужен глобальный стор), автор предложил вместе написать свой. И этот шаг позволил начинающим изучать впоследствии настоящий Redux с хотя бы примерным пониманием того, как оно в целом там всё устроено. За это лайк)

А вот от строковых литералов повсюду, особенно ключевых состояний промиса, кровь из глаз. Енамы нам не завезли, так как тут вроде голый JS, но можно же было например словарь какой-нибудь слепить или просто три строковых константы сделать в крайнем случае, и к ним уже везде обращаться.

[polwen]

Рад, что такой подход вам близок :)

По поводу строковых литералов, согласен. Можно было бы сделать объект для хранения значений, но я решил так не делать, чтобы примеры в тексте читались проще. И читателю не нужно было держать в голове дополнительные переменные, которые не видны в самом фрагменте.