зачем считать реквесты

а куда nodejs код заливать

runkit

runkit

спасибо

зачем считать реквесты

хочется смотреть как циферки бегут :D решение вот тут: https://stackoverflow.com/questions/48010195/nodejs-cluster-global-variables

может тебе просто нормальную статистику завести?

может тебе просто нормальную статистику завести?

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

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

Лол

Страдай

Страдай

наоборот опыта набераюсь

Именно. Это должно быть что-то сложное, куда приходит много разных событий и надо по разному их отслеживать и комбинировать. Я такого на беке не встречал.

ех, жаль - кажется тогда я зря вечер потерял

ех, жаль - кажется тогда я зря вечер потерял

Ну почему, rx вещь занятная. Только одного вечера для нее мало.

Ну почему, rx вещь занятная. Только одного вечера для нее мало.

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

В этой дури причина совсем не в rx.

В этой дури причина совсем не в rx.

а в чём?

я вообще думаю прикрутить rxjsк монгузу) думаю было бы удобно трансформить и валидировать нестед струтктуры

rxdb чекай

rxdb чекай

нежданчик, спасибо =) но в любом случае rxjs мне тоже расковырять-понять нужно

а в чём?

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

Мне иногда кажется что Рхжс — способ добавить лишнего кода

На беке конечно ему сложнее применение найти часто, на фронте очень даже ничего

rxdb чекай

почитал - увы проект на монгузе, вряд ли получится просто так взять и портировать...

разве что заюзать https://www.npmjs.com/package/mongoose-schema-jsonschema и держать на борту обе либы)

Может ли промисифирование повлиять на скорость работы request'а?

Может ли промисифирование повлиять на скорость работы request'а?

Вряд ли, разве что как-то минимально. Имхо - это не должно быть критично

Очень странно... Спасибо.

Очень странно... Спасибо.

Правда если запросов много и часто, и если ты их евейтиш постоянно, то да, тогда будут задержки и неслабые

Мне иногда кажется что Рхжс — способ добавить лишнего кода

Просто это попытка уместить весь event driven в куцый набор хелперов вокруг самой базовой концепции

а в чём?

В криворокости автора. Создавать подписку внутри другой подписки - это трэш и угар. Автор не понимает сути происходящего, следовательно научить чему-то путному не в состоянии

Rx пришел на фронт как раз с бека. А сама реактивная концепция существует не одно десятилетие. Rx - это лишь одна из ее реализаций. Не самая старая и не самая лучшая.

И надо понимать, что вы не очередную либу взялись постигать, а целое направление в программировании. Там свои термины, свои шаблоны проектирования, своя архитектура приложений. Юзать rx как какое нибудь жеквери невозможно, да и бессмысленно. Эта либа даёт возможность работать на реактивных принципах. И это не когда вы пишете код на реакте, а то попадались индивиды, кто всерьез так считает) https://ru.m.wikipedia.org/wiki/Реактивное_программирование https://books.google.ru/books/about/Реактивные_шаблоны_пр.html?id=Ow5BDwAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y

Попадаются индивидуумы которые считают небольшую примитивную ветку event driven программирования целым направлением)

Ну если слово approach переводить как 'направление' то я им пользуюсь вместо промисов

А вообще если гугльнуть то это парадигма

Event driven другая парадигма

Я видимо не так прочитал тоже. Наверно речь о 'реактивной'?

Event driven другая парадигма

Да, и она включает в себя всю реактивность

Скорее наоборот

Rx пришел на фронт как раз с бека. А сама реактивная концепция существует не одно десятилетие. Rx - это лишь одна из ее реализаций. Не самая старая и не самая лучшая.

Спасибо) может сразу поделитесь что с ним делали на беке?

ну а так на те доку, играйся https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

var short = function(message, callback) { ShortUrl.short(message, function (err, url) { callback(url); }); };

Разобрался-таки вчера

благодарю!

И надо понимать, что вы не очередную либу взялись постигать, а целое направление в программировании. Там свои термины, свои шаблоны проектирования, своя архитектура приложений. Юзать rx как какое нибудь жеквери невозможно, да и бессмысленно. Эта либа даёт возможность работать на реактивных принципах. И это не когда вы пишете код на реакте, а то попадались индивиды, кто всерьез так считает) https://ru.m.wikipedia.org/wiki/Реактивное_программирование https://books.google.ru/books/about/Реактивные_шаблоны_пр.html?id=Ow5BDwAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y

Про реакт - не так уж далеко от истины те кто так считают

@Atassis

var short = function(message, callback) { ShortUrl.short(message, function (err, url) { callback(url); }); };

Вам там промис рекомендовали, т.е. вот так: function short(message) { return new Promise((res, rej) => { ShortUrl.short(message, (err, url) => { if (err) { rej(err); return; } res(url); }) }) } Использовать как short(url).then(shorten => ....).catch(err => ...)

Вам там промис рекомендовали, т.е. вот так: function short(message) { return new Promise((res, rej) => { ShortUrl.short(message, (err, url) => { if (err) { rej(err); return; } res(url); }) }) } Использовать как short(url).then(shorten => ....).catch(err => ...)

А зачем там return?

А зачем там return?

После rej?

После rej?

+

+

Чтобы выйти из функции, иначе он после режекта ещё попытается выполнить промис

Ничего страшного но так очевиднее

Если стрелочная то я бы писал через "?"

Ещё очевиднее будет

Не совсем, нам тут из функции ничего возвращать не нужно

Так ничего возвращаться и не будет

=> err ? rej(err) : res(result)

И усе

Ну да, как вариант. Только void для чистоты добавить

Чтобы выйти из функции, иначе он после режекта ещё попытается выполнить промис

Промисы вроде не могут состояние менять

Ничего страшного но так очевиднее

Очевиднее будет return reject без else

Промисы вроде не могут состояние менять

не вроде а точно не могут, имено поэтому я написал что ничего страшного

Очевиднее будет return reject без else

мне не нравится такой вариант потому что выглядит так будто нам reject что то вернет что мы хотим вернуть из функции

@ejnshtein дельно предложил насчет тернарки, но по озвученой выше причине я бы все равно рекомендовал писать вот так function short(message) { return new Promise((res, rej) => { ShortUrl.short(message, (err, url) => { err ? rej(err) : res(result); return; }) }) }

function short(message) { return new Promise((res, rej) => { ShortUrl.short(message, (err, url) => err ? rej(err) : res(result)) }) }

Я бы писал так

function short(message) { return new Promise((res, rej) => { ShortUrl.short(message, (err, url) => err ? rej(err) : res(result)) }) }

да, чуть не забыл, еще одна причина по которой я так не пишу - дебажить не удобно потом

разве? брейкпоинты же умеют останавливаться внутри стрелок

да но как туда его поставить

или я чего-то не знаю?

ну хром позволяет тебе указать точку входа, если их несколько в строке

шторм тоже умеет

как-то через раз у хрома получается этот трюк, если работаешь через sourse map, да и я не редко пользуюсь debugger строкой

да и console.log тоже

ну тогда разговор короткий да

help pls https://toster.ru/q/567101

help pls https://toster.ru/q/567101

>php

>php

подправил

подправил

Php ты не подправишь

Как будто современный ЖС лучше ПХП. По мне так уровень многих ЖСеров будет ниже пыхеров.

@Atassis

Php ты не подправишь

Как еще можно отправить данные идентификатора на сервер, где php.

Как будто современный ЖС лучше ПХП. По мне так уровень многих ЖСеров будет ниже пыхеров.

По тебе )

Как еще можно отправить данные идентификатора на сервер, где php.

Это чат по ноде

Вопрос такой.. Кто пользовался Visual Studio, сталкивался с проблемой бесконечного "Waiting for the debugger to disconnect..."? как решаемо?

По тебе )

По трудовому рынку Германии сужу.