:s/yield/await

Удобнее так: const res1 = await demo1(100); const res2 = await demo2(res1); const res3 = await demo3(res2); Или const res3 = await demo1(100) .then(demo2) .then(demo3);

Законом не запрещено.

второй вариант ИМХО проще и приятнее

Не знаю, мне мешать не нравится.

Не знаю, мне мешать не нравится.

А иногда придётся.

соберу воедино: кто пишет тесты под ноду, что используете? что удобнее?

А иногда придётся.

Хм, нафига?

Пишу на mocha+chai+proxyquire

Хм, нафига?

Эвэйт работает с промисом. Если тебе нужно вписать в эту парадигму какой-то асинхронный интерфейс, который принимает только колбэки, тебе придётся завернуть его в промис.

Хм, нафига?

И вообще, async/await — просто сахар над промисами.

Вопрос. Есть ли возможность чтобы одним из webRTC клиентов был nodejs сервер. Который бы доставлял по socket.io видео поток клиентам остальным. и была бы возможность доставлять видео-поток пользователям с IOS. Ибо их обедили WebRTC. И просто так доставить им видео не выходит. HLS&ffmpeg не совсем то. Так как задержка очень большая выходит. Нужен реальный совет, а не просто первые ссылки с гугла. Буду оч. благодарен.

Эвэйт работает с промисом. Если тебе нужно вписать в эту парадигму какой-то асинхронный интерфейс, который принимает только колбэки, тебе придётся завернуть его в промис.

И? Отдельная arrow fn или обычная fn.

И вообще, async/await — просто сахар над промисами.

+ геренаторы.

Лол.

И? Отдельная arrow fn или обычная fn.

Что отдельная fn?

И? Отдельная arrow fn или обычная fn.

давно выяснили коллбеки говно ))

Пишу на mocha+chai+proxyquire

а нафига столько?

а нафига столько?

Мокка — запуск тестов, чай — ассерт-библиотека, proxyquire — заглушки для зависимостей тестируемого модуля.

sinon еще

> proxyquire фу какая гадость

мне интересно все знают о флаге --inspect?

> proxyquire фу какая гадость

Альтернатива?

Передавать зависимости параметрами функции или конструкторы

Передавать зависимости параметрами функции или конструкторы

И что мы получим? Injection hell? =)

То есть, даже fs и request нужно будет передавать как параметр? Лол.

И только ради тестирования настолько усложнять код?

Тут нет усложнения

Работал так на нескольких проектах

Брат жив

Пробовал rewire

Тут нет усложнения

Пример кода бы.

Оказалось, что он не работает, когда у тебя наследование

А injection hell случается, когда в коде плохие абстракции

Оказалось, что он не работает, когда у тебя наследование

rewire в принципе не работает. ы.

То есть если ты передаешь 10 зависимостей, то значит, у тебя плохой дизайн

А модули это всего лишь неймспейсы

А injection hell случается, когда в коде плохие абстракции

Да, в любом случае, где-то в коде есть место, где ты передаёшь зависимость.

Не надо через require инжектить пожалуйста

Я вижу только один адекватный путь — передавать зависимости перед объявлением модуля, объявляя модуль как функцию.

В то же самое время, где-то в коде будет место, где я делаю так: import fs from 'fs'; import myModuleInit from './my-module'; const myModule = myModuleInit({ fs }); С myModule всё понятно, но как ЭТОТ код тестировать?

Объявлять так же, как myModule? Тогда список зависимостей ближе к верхнему уровню будет расти.

Ну и нафиг оно нужно?

Не надо через require инжектить пожалуйста

Почему?

тут скорее надо знать границу

lodash и moment например нет смысл подменять

lodash и moment например нет смысл подменять

+

что проще всего?

ava

Депенси инъекшн — это не повсеместный подход. Он хорош там, где зависимость заменяема и имеет стандартный внешний интерфейс.

fs тоже очень зависит, а например сервис, который на базе фс реализует какой-нибудь репозиторий - есть

Иначе нафига?

fs тоже очень зависит, а например сервис, который на базе фс реализует какой-нибудь репозиторий - есть

Мне кажется, всегда нужно менять то, что обращается к неизвестным данным.

Неизвестные данные — те, которых нет в репозитории.

БД, файлы, соединения, прочая фигня.

Депенси инъекшн — это не повсеместный подход. Он хорош там, где зависимость заменяема и имеет стандартный внешний интерфейс.

Продолжая эту мысль, повсеместное применение этого подхода приведёт к неоправданному усложнению.

хорошо что google amp использует drake hotline bling в качестве примера iframe'а

call me on my cell phone

Депенси инъекшн — это не повсеместный подход. Он хорош там, где зависимость заменяема и имеет стандартный внешний интерфейс.

Если тебе требуется proxyquire, значит ты делаешь что-то не так

как не повсеместный? :(

надо на flow переходить или typescript

попроще же будет

Но тебе всегда требуется делать всё своим особым костылём, так что я даже не удивлен уже)

> @klond90 надо на flow переходить или typescript

Не дай бог кто удалить Трампа еще раз

ERROR: S client not available

хилари фаны кругом? :(

Хороший президент ?

Стикеры вне политики

Это просто стикеры

Если тебе требуется proxyquire, значит ты делаешь что-то не так

Ну как так?

Ну вот так

чуваки в jest юзают аналог proxyquire

let sym = Symbol(); {}+sym VM400:1 Uncaught TypeError: Cannot convert a Symbol value to a number sym+{} VM466:1 Uncaught TypeError: Cannot convert a Symbol value to a string

все верно. символы не коерcятся

Если тебе требуется proxyquire, значит ты делаешь что-то не так

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

надо на flow переходить или typescript

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

flow это не транспайлер.

для ноды лучше взять flow имхо

чтобы быть уверенным в выходном коде

для фронта тс лучше

ну и вообще без статических ошибок в рантайме ловить ошибки очень геморойно и стремно лучше уж совсем глупые опечатки и т.д. убирать :/

flow это не транспайлер.

технически - транспайлер

В js есть либы для рантайм типизации, только ими никто не пользуется

они не нужны

типо assert?

Это тождественно

типо assert?

Нет, типизация , а не ассерт

рантайми типизация это не круто же

ну где-нибудь где ты ждешь ответа от базы или каких-то левых источников ок а в своем же коде такие штуки вводить чот стремно

кажется описание json схемы актуальнее

для данных с внешнго сервиса

ну по сути да transpiler в реальности же код не удаляется ничего от себя не добавляет тьфу тьфу

ну где-нибудь где ты ждешь ответа от базы или каких-то левых источников ок а в своем же коде такие штуки вводить чот стремно

Но эта проблема же как-то решается в языках с сильной типизацией?

Optional ?

монады <3

Ну это и в js есть

Причём даже не один вариант