Последовательный fetch и 5 способов решения

Это я не конкретно этот пример описываю, а вообще. Когда вы начинаете считать строчки кода, задумайтесь — а оно вам надо?

И я полностью согласен с вашими доводами по сложности кода и количеству строк. Просто нужно было хоть как-то оценить разные подходы в сравнении(и это только в рамках заметки на habr). Как я и написал, я не придумал другого способа оценки. Но если вы можете предложить нечто более подходящее — я с радостью перепишу раздел с выводами.

Последовательный fetch и 5 способов решения

Если сильно хочется иметь на выходе именно синхронную функцию

не было такого непреодолимого желания. Ваш вариант тоже имеет место быть, только тогда надо его привести в общий вид, примерно, так:

function makeRequests(urls, initialData, callback) {
  let result = Promise.resolve(initialData);
  for (const url of urls) {
    result = result
      .then(res => fakeFetch(url, res));
  }

  return result
    .then(res => callback(null, res);
}

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

Последовательный fetch и 5 способов решения

Я с вами полностью согласен, но я попытался реализовать ровно те способы решения, которые предлагали сходу кандидаты.
В любом случае, если вам необходимо еще проверить умение работы с гененераторами/рекурсиями/AsyncAwait/Reduce/For of, то это можно сделать в рамках одной задачи, нежели на каждый случай формулировать новую.

Последовательный fetch и 5 способов решения

Вы точно знаете что такое простой, легко и быстро воспринимаемый и читаемый код?

Думаю, это довольно субъективное мнение. Но все, надеюсь, согласятся с тем, что решение с использованием генераторов намного более громоздкое и не наглядное (или все же кто-то считает иначе?). Именно это и было целью этой заметки. А еще рассуждения на тему того, что у любой задачи есть несколько решений, и в каждом конкретном случае, какие-то подходы могут быть избыточны или громоздки.

Последовательный fetch и 5 способов решения

еще раз повторюсь: цель собеседования — посмотреть на ход мыслей и опыт интервьюируемого. Что бы он не предложил в качестве решения, все равно будут обсуждаться разные решения, которыми можно было бы решить задачу. А уже в ходе обсуждения становятся видны достоинства и недостатки каждого решения.

Ваш вариант с reduce это как раз то, что мне пришло в голову в самую первую очередь

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

двигался бы в сторону решения которое нравится интервьюверу

то что интервьювер ожидал и что ему нравится — разные вещи.

Если бы от кандидата требовалось только решение задачи, это происходило бы с помощью инструментов онлайн тестирования. Но это не спортивное программирование. Именно поэтому, подобные задачи обсуждаются и решаются у доски (так называемый white board interview)

возвращет Promise (как вам вообще в голову идея с callback пришла в 2020)

callback для возвращения использовался только для того, чтоб постараться поставить все решения в одинаковые условия (и делалось это только для заметки на habr), потому что в случае к возвращением промиса, например, рекурсия или reduce получат преимущества в виде уменьшения кода на одну строку, так как можно будет просто сделать:

return url.reduce

В случае же с генераторами и асинхронными генераторами этого не выйдет.
Но тем не менее, даже в 2020 году callback все еще используется, как минимум на стороне сервера, например, загляните посмотрите в сторону NodeJs: nodejs.org/api/fs.html

Последовательный fetch и 5 способов решения

Не могу не согласиться. Никто не поддает сомнению, что императивные for быстрее в несколько раз функций высшего порядка.

И forEach, в свою очередь, быстрее map (хотя в случае с forEach это происходит скорее из-за того, что forEach просто вызывает callBack функцию не дожидаясь результатов).

Но, тем не менее, функции высшего порядка на порядок нагляднее (разумеется, это субъективное мнение). А Также присутствует возможность чейнинга, что увеличивает наглядность в сложных случаях, хоть и за счет производительности.

Последовательный fetch и 5 способов решения

Разве на подобных собеседованиях не принято искать того кто будет разгребать говны написанные собеседующими

на мой взгляд, основная цель собеседования — не опустить всеми методами интервьюируемого, как в армии, а посмотреть его ход мыслей и проверить опыт. Именно поэтому, на white board интервью в силиконовой долине, за решение принимается даже псевдокод для алгоритмических задач.

выделяет лишнюю память на promise обертки

Напомню, что функция с ключевым словом async всегда возвращает промис. Значения других типов оборачиваются в завершившийся успешно промис автоматически.

— выделяет лишнюю память на функцию аккумуляции, то есть GC лишний раз будет дергаться

Для переменной const url в цикле for, тоже выделяется память, при чем она выделяется на каждой итерации кода.

— не короче чем «for of»:

«for of» тоже может быть решением, но тогда давайте объективно оценивать. А для этого нам этот код надо привести в общий вид, произведя форматирование кода. Потому что reduce тоже можно превратить в однострочник, только это будет не объективно.
И тогда код приобретет примерно следующий вид:

async function seriesFetch(callback) {
  let result;
  for (const url of urls) {
    result = await fakeFetch(url, result);
  };
  callback(result);
}

В таком варианте уже можно сравнивать объективнее.

Новичков считающих себя «не новичками» можно определить по использованию reduce там где этого не требуется.

Оценил ваш сарказм