фуфуфу

demo1(100) .then(demo2) .then(demo3)

все пишут

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

хотя стоп

или удобнее

return demo3(demo2(demo1(yield Promise.resolve(100))));

А зачем на генераторы?

Почему не асинки?

лучше всего на async/await )))

: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 тоже очень зависит, а например сервис, который на базе фс реализует какой-нибудь репозиторий - есть

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

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

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

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

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

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

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

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

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

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

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

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

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

Если тебе требуется 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, значит ты делаешь что-то не так

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

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