Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

06-promises-tasks.js #58

Open
Elijah-I opened this issue Nov 27, 2022 · 3 comments
Open

06-promises-tasks.js #58

Elijah-I opened this issue Nov 27, 2022 · 3 comments

Comments

@Elijah-I
Copy link

Я заметил что тут неправильно сделаны тесты.

Если я все так понял - суть промисов в асинхронности, но тесты принимают синхронный код
потому что использутеся

const promises = [ Promise.resolve(1), Promise.resolve(2), Promise.resolve(3) ]

которые резолвятся тут же

Я вроде как понимаю, что из стека вызова они все равно уходят в асинхронное web API, оттуда попадают в Task Queue и уже потом возвращаются в stack.
Но тем не менее просто синхронный код через for проходит тесты. А если добавить реальной задержки промису:

const promises = [ new Promise((res) => { setTimeout(() => res(1), 1000) }), Promise.resolve(2), Promise.resolve(3) ]

вот тогда все сломается как и положено и синхронный код уже не пройдет тест

@DimaBLR
Copy link

DimaBLR commented Nov 27, 2022

"вроде как понимаю, что из стека вызова они все равно уходят в асинхронное web API" -> нет, не понимаешь.
Если промисы уходят в web api, то для чего тогда нужен Task Queue, и в чем разница между ним и web api ?

@bloodsuckers-spb
Copy link

bloodsuckers-spb commented Nov 27, 2022

в тестах не учтено, что промисы могут резолвиться разное количество времени и соответственно значения могут поменять свой порядок в результирующем массиве если их туда пушить, а не присваивать по индексу, а так же конфиг линтера настроен таким образом, что он не позволяет создать счётчик и написать проверку, что бы резолвить результирующий массив, когда, количество в нем значений (без пустот) будет соответствовать исходному массиву с промисами

@Elijah-I
Copy link
Author

Elijah-I commented Nov 28, 2022

"вроде как понимаю, что из стека вызова они все равно уходят в асинхронное web API" -> нет, не понимаешь. Если промисы уходят в web api, то для чего тогда нужен Task Queue, и в чем разница между ним и web api ?

Ну как я себе это вижу:

  1. из стека вызова асинхронщина уходит как задача в web api, соответственно в стеке она убирается, как выполненная
  2. когда асинхронный код выполнится в web api он поместит результат выполнения в Task Queue
  3. event loop следит за Task Queue и стеком. Как только в стеке закончатся задачи - event loop начнет брать по очереди то, что есть в Task Queue и закидывать в стек

Т.о. даже если время резолва промиса = 0, то он все равно попадет в web api, там мгновенно зарезолвится и затем то, что он вернул попадет в Task Queue, а оттуда обратно в стек уже после того, как все синхронные задачи в стеке будут выполнены

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants