Велосипедим Promise на TypeScript

[SergeyPeskov]

1) Думаю вам стоит добавить типы(generic) для метода then, не очень удобно, что сейчас у ConsumerCallback параметр argument всегда имеет тип any.

2) А почему вы не взяли queueMicrotask вместо setTimeout?

[yangirekun]

Здравствуйте!

1) Тоже думал об этом, но позже пришел к выводу, что типизация подписчиков для конечного пользователя через дженерики не имеет особого смысла. Конструкции на скриншоте полностью идентичны, впрочем, это самый простой кейс, поправьте меня, если я что - то упустил или мы говорим о разном.

2) В целях сделать текст чуть проще, setTimeout это основа основ, которая интуитивно понятна любому разработчику, в то время как сравнительно недавно появившийся queueMicrotask, на практике, используется совсем редко.

[SergeyPeskov]

Добрый день!

Я немного про другое.
- Можно было бы добавить тип для класса(PromiseImplementation<T>) и пробросить его в resolve, чтобы было не (argument?: any) => void , а (argument?: T) => void и тогда этот тип можно использовать для then (argument?: T) => any;

- Когда у нас есть цепочка промисов, можно добавить получение типа для then на основе возвращаемого значения.

[yangirekun]

Теперь понял, про что речь. Благодарю за разъяснения, чуть позже улучшу код в репозитории и статье.

[wdhappyk]

Но тогда реализация нарушает постановку задач в движке js, т.к. promise создаёт микротаски, а не макро

[yangirekun]

Добрый день!

> promise создаёт микротаски, а не макро

Все верно. Об этом было упомянуто в самом конце, возможно стоит подсветить это более явно.

Не совсем понял формулировку "нарушает постановку задач". Скорее всего вы говорите про примеры совместного использования промисов и webAPI, в которых действительно можно увидеть разницу между велосипедом, и тем, как оно работает нативно:

// macrotask queue
setTimeout(() => { console.log(1); }, 0);
PromiseImplementation.resolve().then((x) => { console.log(2); });
console.log(3);
// Output: 3, 1, 2

// microtask queue
setTimeout(() => { console.log(1); }, 0);
Promise.resolve().then(() => { console.log(2); });
console.log(3);
// Output: 3, 2, 1

Мне в голову не пришел адекватный сценарий, при котором такие отличия в работе могут повлиять на заложенную в коде логику. Ввиду этого, использование setTimeout вместо queueMicrotask, показалось допустимым упрощением. Всё таки основной фокус немного на другом.

Разумеется, при разработке промышленного полифила, было бы необходимо учесть и такой кейс. Но тогда бы пришлось использовать setimmediate для IE / Node.js или что - то ещё для конкретной среды. Промисы и queueMicrotask, друг без друга, в природе не встречаются.