и это на самом деле очень круто, что вы это написали. Вы согласны с тем что эта задача не настолько тривиальна, как кажется на первый взгляд?
Завернуть всё это в красивый интерфейс – давайте исходить из того что в красивый интерефейс можно что угодно завернуть
вот тут есть код условного сервер. Почему если я меняю код вашего емулятора промисов на реальный реквест, то вижу только 5 запросов начинает происходить что-то странное?
а можно попросить вас показать пример метода, который вы «запихаете» в lodash? Это не комментарий в стиле – сами напишите статью. Просто попробуйте мысленно реализовать этот метод, и, мне кажется, вы поймете «где здесь потоки данных и распространение изменений?»
>Материя стала более прочной, и я создал несколько разных физических материалов: камень, металл, снег, песок, земля, лёд, желе, и т.д.
Почти Библия. Очень вдохновляющий рассказ
bano-notit
вы не поверите, но таки пресдтавленный maxxon код «почти»(с оговорками для ноды) паралельный и медленнее того который с Promise.all на ~2ms – и то, есть вероятность, что это лаг, а не реальное замедление
Другой вопрос – что это не очевидно, и синкаксически его код не показывает что он «паралельнный»
>Без обид, но ваш комментарий — типичная логика современного разработчика
Без обид, но ваш комментарий – типичная логика «несовременных» разработчиков-одиночек любяших все держать под контроллем(мнимым). По запросу «jquery minimal» вы могли найти вагон и маленькую тележку библиотек минимального размера, вроде Zepto(~10kb, но я думаю можно вложится в 2kb или меньше, если собрать только, то что нужно). Но вы сознательно сделали все на коленке и к эффективности это не имеет никакого отношения. Если вы ставили себе целью – разобраться, то ок – но не рассказывайте про эффективность
Есть еще второй вариант – вы сделали обзор существующих решений и пришли к выводу что они не подходят, потом разработали свою уникальную библиотеку. Тогда не томите – github ждет
>bricks — это набор функции, которые возвращают промис.
params.bricksForModule[userdata.moduleType] – тоесть это promise? или функция – если функция, то когда она вызывается?
За пример кода – спасибо. В принципе увидел, то что хотел.
я ничего не думаю – увидел опечатку, сказал вам об этом. Вам достаточно было проигнорировать это или просто сказать – опечатка.
В следующий раз буду ставить много много смайликов – чтобы вы не подумали что я хочу вас обидеть
нет – со стороны выглядит будто вы этот кусок вырезали из кода, не меняя имен переменных. Но, в принципе, не суть.
Не хотел вас поддеть или как-то обидеть
с точкой зрения:
>PS дихотомия между отверткой и молотком — ложная. Нужны оба инструмента!
я вполне согласен – ваш первый пример, если его вдумчиво «покурить», показал что есть ситуация в которой async/await упрощает жизнь. Но в статье об этом ни слова.
Про ваш второй пример – я такого сказать не могу. Ну заменили вы .then на await. Вроде как стало на один уровень вложености меньше, но стоит вам добавить обработку исключений и все вернестя на свои места.
то что вам не нужно пробрасывать через .then пары аргументов – это плюс.
Ну и он страно написан – await Promise.all(bricks). возможно вы где-то кусок кода удалили – но, даже так, это странно складывать промисы и что-то «статитеское» в один и тот же список. Скорее кто-то на всякий случай обернул чтобы не думать что там внутри. Есть еще вариант, что там в params промисы где-то лежат – но это тоже странно.
>По сути, обычно…
бывает по разному. давайте все же смотреть на картину в целом.
>А когда она требуется, то просто делается все через Promise.all
Если вас не затруднит, проилюстрируйте свою идею кодом — по, возможности, перепишите код из этого комментария https://habrahabr.ru/company/ruvds/blog/326074/#comment_10166298 , само сабой – с учетом опечатки и без break так чтобы делало как можно больше запросов «паралельно»
>Вот зачем вы пишите Promise.resolve(queryList).map(getType) — когда можно написать queryList.map(getType)?
Эти два куска кода совсем не эквиваленты. Посыл был показать concurrent и что выполнить n-запросов один за другим – это далеко не тоже самое что выполнить n-запросов «сразу». И что это важно – понимать эту разницу. Но это никто в упор не хочет видеть.
проблема вашего и моего кода в другом – мы делаем лишние вызовы к getType.
>PS дихотомия между отверткой и молотком — ложная. Нужны оба инструмента!
Отличная мысль! давайте еще раз глянем в заглавие статьи. А потом посмотрим на примеры из нее – я не вижу там того что показал Shannon, но не смог сформулировать
А нужно было показать что в случаях с циклами с пост-условием(вот этот break) нам, таки, намного легче писать с async/await – и пофиг что это некрасиво, не-functional и вообще почти GOTO. И, наверное есть еще подобные примеры
В статье и комментариях я вижу как раз то о чем вы написали:
Promise.resolve([1, 2, 3]).map(getType)
сложнее чем(и впридачу, еквивалентно)
[1, 2, 3].map(query => {
const type = await getType(query);
return type
})
только в действительности первый вариант будет выполнятcя ~n времени(конечно, с оговорками), а второй 3*n времени. И если эту разницу игнорировать – то нам вообще не нужен async/await(как и promise), нам просто нужно синхронное IO
я вам привел как это будет выглядеть, сложности тут особой нет.
Дальше – рассуждайте сами, какой подход вам более покажется преемлемым
вопрос исключительно в том что стоит показывать равносильные примеры, а не те в которых один подход явно выгодней другого, но это не к вам вопрос – а к статье
Завернуть всё это в красивый интерфейс – давайте исходить из того что в красивый интерефейс можно что угодно завернуть
то вижу только 5 запросовначинает происходить что-то странное?Почти Библия. Очень вдохновляющий рассказ
вы не поверите, но таки пресдтавленный maxxon код «почти»(с оговорками для ноды) паралельный и медленнее того который с Promise.all на ~2ms – и то, есть вероятность, что это лаг, а не реальное замедление
Другой вопрос – что это не очевидно, и синкаксически его код не показывает что он «паралельнный»
Без обид, но ваш комментарий – типичная логика «несовременных» разработчиков-одиночек любяших все держать под контроллем(мнимым). По запросу «jquery minimal» вы могли найти вагон и маленькую тележку библиотек минимального размера, вроде Zepto(~10kb, но я думаю можно вложится в 2kb или меньше, если собрать только, то что нужно). Но вы сознательно сделали все на коленке и к эффективности это не имеет никакого отношения. Если вы ставили себе целью – разобраться, то ок – но не рассказывайте про эффективность
Есть еще второй вариант – вы сделали обзор существующих решений и пришли к выводу что они не подходят, потом разработали свою уникальную библиотеку. Тогда не томите – github ждет
из плюсов:
не меняет порядок эллеметов( у вас promiseList «как бы упорядочен»)
В общем – спасибо за пример. Ну и всегда приятно пообщатся с человеком который подкрепляет свои суждения кодом. Приятных
params.bricksForModule[userdata.moduleType] – тоесть это promise? или функция – если функция, то когда она вызывается?
За пример кода – спасибо. В принципе увидел, то что хотел.
В следующий раз буду ставить много много смайликов – чтобы вы не подумали что я хочу вас обидеть
Не хотел вас поддеть или как-то обидеть
с точкой зрения:
>PS дихотомия между отверткой и молотком — ложная. Нужны оба инструмента!
я вполне согласен – ваш первый пример, если его вдумчиво «покурить», показал что есть ситуация в которой async/await упрощает жизнь. Но в статье об этом ни слова.
Про ваш второй пример – я такого сказать не могу. Ну заменили вы .then на await. Вроде как стало на один уровень вложености меньше, но стоит вам добавить обработку исключений и все вернестя на свои места.
то что вам не нужно пробрасывать через .then пары аргументов – это плюс.
Ну и он страно написан – await Promise.all(bricks). возможно вы где-то кусок кода удалили – но, даже так, это странно складывать промисы и что-то «статитеское» в один и тот же список. Скорее кто-то на всякий случай обернул чтобы не думать что там внутри. Есть еще вариант, что там в params промисы где-то лежат – но это тоже странно.
>По сути, обычно…
бывает по разному. давайте все же смотреть на картину в целом.
>А когда она требуется, то просто делается все через Promise.all
Если вас не затруднит, проилюстрируйте свою идею кодом — по, возможности, перепишите код из этого комментария
https://habrahabr.ru/company/ruvds/blog/326074/#comment_10166298 , само сабой – с учетом опечатки и без break так чтобы делало как можно больше запросов «паралельно»
Эти два куска кода совсем не эквиваленты. Посыл был показать concurrent и что выполнить n-запросов один за другим – это далеко не тоже самое что выполнить n-запросов «сразу». И что это важно – понимать эту разницу. Но это никто в упор не хочет видеть.
проблема вашего и моего кода в другом – мы делаем лишние вызовы к getType.
>PS дихотомия между отверткой и молотком — ложная. Нужны оба инструмента!
Отличная мысль! давайте еще раз глянем в заглавие статьи. А потом посмотрим на примеры из нее – я не вижу там того что показал Shannon, но не смог сформулировать
А нужно было показать что в случаях с циклами с пост-условием(вот этот break) нам, таки, намного легче писать с async/await – и пофиг что это некрасиво, не-functional и вообще почти GOTO. И, наверное есть еще подобные примеры
В статье и комментариях я вижу как раз то о чем вы написали:
сложнее чем(и впридачу, еквивалентно)
только в действительности первый вариант будет выполнятcя ~n времени(конечно, с оговорками), а второй 3*n времени. И если эту разницу игнорировать – то нам вообще не нужен async/await(как и promise), нам просто нужно синхронное IO
Если я что-то не понимаю – прошу поправить
Дальше – рассуждайте сами, какой подход вам более покажется преемлемым
вопрос исключительно в том что стоит показывать равносильные примеры, а не те в которых один подход явно выгодней другого, но это не к вам вопрос – а к статье