и мы можем применить это для любого компонента

вы меня не поняли, так что лучше мне показать код

Это не реакт чат

так или иначе мы обсуждаем наследование

ну композиция явно лучше в случае реакт. инкапсуляция логики работы со стейтом и конечного отображения

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

на этом тут закончим

извините

class MyAwesomeComponent extends React.Component { clearState() { ... } } например

А кто подскажет в каких отношениях эта либа https://www.npmjs.com/package/promise с нативными промисами?

А кто подскажет в каких отношениях эта либа https://www.npmjs.com/package/promise с нативными промисами?

Исходный код подскажет

Я к тому что будет ли на ней await работать

А вообще A+ это совместимость со спекой

Я к тому что будет ли на ней await работать

Зачем тебе либа?

Не конкретно она, но на ней собрано хренова туча А+ библиотек

Хочу найти монго драйвер на промисах а нативных нет, только на этой либе

Хочу найти монго драйвер на промисах а нативных нет, только на этой либе

обычный mongodb на нативных промисах http://mongodb.github.io/node-mongodb-native/

Под koa лучше юзать mongoose или mongo-koa?

В чем между ними разница?

обычный mongodb на нативных промисах http://mongodb.github.io/node-mongodb-native/

Калбэки же везде

Калбэки же везде

либо cb либо then

then лутше

* @return {Promise} returns Promise if no callback passed То есть если просто не передавать калбэки то все функции возвращают промисы?

Мне кажется эта особенность плохо отражена в документации, я вот о ней и не подозревал

Мне кажется эта особенность плохо отражена в документации, я вот о ней и не подозревал

да вроде к каждому методу дописано findOne(query, options, callback){Promise}

var foo = 1; (function (foo) { if (!foo) { var foo = 2; } console.log(foo); })(foo);

Сча быстренько все полезли выполнять в console

Да вроде все просто

В этом случае будет 1 =)

var foo = 1; (function (foo) { if (!foo) { var foo = 2; } console.log(foo); })();

Но если так, то 2 )

ну, очевидно

Сча быстренько все полезли выполнять в console

манипулируешь людьми

так тут же просто все

Очивидно, то что сначала объявляются локальные переменные в функции и JS похер будет это var или аргумент. И после он присваивает значение в локальный foo, а через, что он был объявлен глубоко насрать

var foo = 1; (function () { if (!foo) { var foo = 2; } console.log(foo); })();

Вот еще примерчик

Уже без объявления аргумента

Ну да

Опять же, это все более менее очевидные вещи

Но на эту тему есть хардкорные тесты

https://habrahabr.ru/company/paysto/blog/251329/

Не для них

Неиспользование var решает часть вопросов

http://esprima.org/demo/parse.html

Esprima, acorn, babylon

http://perfectionkills.com/javascript-quiz/

Не, это не хардкорный

Чет тест какой-то не хардкорный )

Даже Object instanceof Function Function instanceof Object

нет

там продолжение есть

http://perfectionkills.com/javascript-quiz-es6/

Там на швабр какую-то фигню принесли под видом задачек на собеседование.

Может, кому понравится =).

Там на швабр какую-то фигню принесли под видом задачек на собеседование.

Ссылку, пожалуйста.

+1

https://habrahabr.ru/post/322568/

Всем привет. Очередной вопрос от новичка в мире nodejs :) Пишу бота, при получении запроса от юзера, это запрос начинается обрабатываться в главном контроллере, и дальше в зависимости от разных параметров, запрос уходит по каскаду в другие ниже лежащие контроллеры. Т.е. запрос проходит через кучу мелких методов обработчиков, слава богу я вовремя познакомился с Promise. Собственно вопрос: это нормально что у меня в каждом методе обработчике создается свой Promise и отдается обработчику выше, чтобы например получить централизованный обработчик ошибок в главном контроллере? Меня мучают сомнения, потому что получается что на каждый запрос создаются куча одноразовых объектов промисей. Повторю еще раз вопрос: правильно ли в каждом мелком обработчике создавать Promise и передавать контроллеру выше?

Да, это вполне нормально, если везде происходят асинхронные операции, то естественно, что результат выполнения каждой из них передаётся в виде промиса

Если критична скорость выполнения (я бы не сказал, что это частый кейс) - то можно использовать bluebird вместо стандартных промисов

https://habrahabr.ru/post/322568/

+1 Спасибо!

Если критична скорость выполнения (я бы не сказал, что это частый кейс) - то можно использовать bluebird вместо стандартных промисов

Можно подробнее как bluebird поможет в скорости?

ERROR: S client not available

Если критична скорость выполнения (я бы не сказал, что это частый кейс) - то можно использовать bluebird вместо стандартных промисов

Он просто во многом удобнее

Ооо, это да))

Я привыкнув к его разнообразным методам уже не хочу на нативные)

Можно подробнее как bluebird поможет в скорости?

Ну он банально выполняется быстрее нативных

Ну он банально выполняется быстрее нативных

Можно подтверждение?

Подробные бенчмарки на официальном сайте проекта

http://softwareengineering.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird

первая ссылка в гугле

http://ciplogic.com/index.php/blog/92-native-vs-bluebird-vs-core-promise-benchmark

первая ссылка в гугле

Не увидел "быстрее"

Если критична скорость выполнения (я бы не сказал, что это частый кейс) - то можно использовать bluebird вместо стандартных промисов

у меня и так bluebird)

Удобнее согласен, но чтобы быстрее... удивлён.

Я не прав. Bluebird быстрее нативных промисов. Спасибо. https://blog.wikimedia.org/2017/02/17/node-6-wikimedia/

Да сколько раз уже обсуждали это

Да сколько раз уже обсуждали это

Как-то упустил.

Он игнорит некоторые нюансы реализации от нативных. Например, на блюберде можно сделать рекурсию

Он игнорит некоторые нюансы реализации от нативных. Например, на блюберде можно сделать рекурсию

Моё заблуждение было в том, что bluebird обертка над нативными промисами.

Hello! Is there anybody who is interested in voice conversations about JavaScript? I offer to have regular voice sessions via Skype, one session per week, 1-hour duration. The topic for the conversations is programming. I mostly a node.js developer, but I’m interested in modern front-end too. I have two aims for such conversations. First, I really like to speak about programming. I work as a remote contractor, so I don't have an opportunity to discuss programming topics with coworkers. Second, I want to practice my spoken English. I'm not a native English speaker, but my English tutor swears that my English is good enough, so there should not be any problems with it. If you are interested in it, please PM me.

Практиковаться лучше в англоязычных странах

Хэлоу, комрад. Иф ю вант ту спик бэттер зен я ду нау, гоу ту инглишь чатс энд конверсэйшонс бекоуз иф ю спик виз рашнс ю вилл невер импрове йор инглишь лэвэл

Читаю статью http://frontender.info/optimization-killers/, наткнулся на: Вы можете создавать неперечисляемые свойства с помощью Object.defineProperty (не рекомендуется делать в реальном времени, но отлично подходит для определения статических штук наподобие свойств прототипа). Что то стало непосебе, у меня много где Object.defineProperty используется в реальном времени. Прокоментируйте пожалуйста, почему это делать не рекомендуется?

Ну такое если у тебя не общая библиотека то подстраиваться под компилятор смысл нет. Он когда-нибудь станет умнее.

Ну такое если у тебя не общая библиотека то подстраиваться под компилятор смысл нет. Он когда-нибудь станет умнее.

не уловил мысли. Не совсем понятно что значит когда нибудь станет умнее))) я через пару недель закончу своего бота на nodejs, и не хочу что бы у меня были места снижающие производительтность :)

Пройдись деоптом

И оптом

Посмотри что у тебя деоптимизировано. Ну там лучше лекцию Егорова посмотреть

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

Посмотри что у тебя деоптимизировано. Ну там лучше лекцию Егорова посмотреть

ссылку дайте пжалуйста)

https://youtu.be/HPFARivHJRY must see