javascript-tutorial
Несколько замечаний относительно раздела "Промисы".
- В тексте о промисах "https://learn.javascript.ru/promise-basics" есть странный текст:
"Почему так? Скоро нам станет понятно."
Вы не могли бы написать сразу в чём дело или дать ссылку? Не заставляйте читателя читать дальше. Даже не понятно, сколько ещё надо прочитать и где ответ.
-
Мне кажется, что текст "Обработчик finally «пропускает» результат или ошибку дальше, к последующим обработчикам." ошибочный. Может это промис, созданный методом finally, а не обработчик, «пропускает» результат или ошибку дальше, к последующим обработчикам?
-
Почему, если не ошибаюсь, нигде в этом разделе нет информации о том, что при вызове методов then, catch, finally создаётся новый промис? Для кого-то это может показаться очевидным, кто-то может это понять исходя из текста "у промисов также есть метод finally", но мне кажется что луше написать об этом, чтобы было ясно без домыслов. Это может помочь тем, кто учит язык.
Да и вообще, мне кажется, что называть обработчиком функцию, передаваемую в метод finally, неправильно. Она ведь ничего не обрабатывает.
А может имеется ввиду обработка изменения состояния промиса, по аналогии с обработчиком событий? Но там обработчиком называют саму функцию, вызываемую, когда происходит событие, а в учебнике часто используется формулировка "обработчик then/catch/finally". И еще - формулировка "Обработчик, вызываемый из finally" звучит странно.
Так как изменение состояния может не произойти, если метод then/catch/finally был вызван на промисе, который уже завершён ИЛИ ОТКЛОНЁН, то может это просто обработчик состояния?
С другой стороны в обработчик события передаётся информация о событии, а в функцию передаваемую в finally, ничего не передаётся, это скорее функция обратного вызова.
"Обработчик (handler) -- это функция, которая вызывается какой-либо программной системой в ответ на наступление какого-либо события. Чтобы система поняла, что надо вызывать именно эту функцию в ответ на это событие, обычно необходимо обратиться к какому-то специальной функции регистрации обработчиков событий."
Я был не прав. Выходит, что это всё таки обработчик, хотя ситуация с "изменением" состояния, то есть событием, запутанная.
Дополнительно, мне кажется, что раздел Микрозадачи должен быть перед разделом Промисы, чтобы обсуждая методы then/catch/finally можно было сразу объяснить читателю, как и когда будут вызваны функции передаваемые в эти методы. Микрозадачи можно объяснить на примере метода queueMicrotask().
Раз уж я затронул раздел "Микрозадачи", я не могу не процитировать текст "Асинхронные задачи требуют правильного управления.". Это шутка? Какие-то задачи не требуют правильного управления?
Вот еще люди пишут об ошибках - https://github.com/javascript-tutorial/ru.javascript.info/issues/917
Вы вообще собираетесь что-то изменять или так и будете эту дичь лелеять? Если нет времени, найдите кого-то другого, у кого есть. Вы же вводите читателя в заблуждение.
От себя добавлю, что во всем разделе про промисы не было упоминания про то, что код в промисах выносится в отдельный поток выполнения.
От себя добавлю, что во всем разделе про промисы не было упоминания про то, что код в промисах выносится в отдельный поток выполнения.
Что за "код в промисах"?
Что за "код в промисах"?
new Promise((resolve, reject) => {
// какие-то вычисления
});
Вот эти самые какие-то вычисления будут выполняться в соседнем потоке.
В принципе, этот вывод можно сделать после прочтения раздела "Микрозадачи", но нигде явного упоминания нет.
new Promise((resolve, reject) => { // какие-то вычисления });Вот эти самые какие-то вычисления будут выполняться в соседнем потоке.
В принципе, этот вывод можно сделать после прочтения раздела "Микрозадачи", но нигде явного упоминания нет.
Это не "код в промисах", а исполнитель - функция обратного вызова, которую передают в конструктор промиса. Эта функция выполняется в том-же потоке, этоже не метод API и не Web Worker.
Точнее это не методы API, а некоторые операции Web API выполняются в другом потоке или других потоках. Например метод fetch(), входящий в состав Fetch API, выполняет определённые операции в другом потоке, но создаёт промис в том-же потоке, в котором работает скрипт. В другом потоке выполняются прежде всего сетевые операции, но кроме этого в другом потоке также происходит добавление вызова resolve/reject в очередь микрозадач, когда приходит сетевой ответ.
в другом потоке также происходит добавление вызова resolve/reject в очередь микрозадач
Даже не знаю, может более коректно будет сказать/написать, что в очередь микрозадач добавляется операция вызова оставшейся части исполнителя, по аналогии с функцией async, выполнение которой было прервано вызовом кода с оператором await. Или говоря по другому, в очередь микрозадач добавляется операция возобновления выполнения исполнителя.
в другом потоке также происходит добавление вызова resolve/reject в очередь микрозадач
Даже не знаю, может более коректно будет сказать/написать, что в очередь микрозадач добавляется операция вызова оставшейся части исполнителя, по аналогии с функцией async, выполнение которой было прервано вызовом кода с оператором await. Или говоря по другому, в очередь микрозадач добавляется операция возобновления выполнения исполнителя.
Мне кажется, самый оптимальный вариант: после получения сетевого ответа, а точнее заголовков ответа или в случае ошибки, в очередь микрозадач добавляется операция изменения состояния промиса, возвращённого методом fetch.