Когда ознакомился с документацией React'а, понравилось наверное то, что есть классы, есть наследование (скажем так). Понравилось наверное то, что пришёл с мира Java (Android; Android SDK).

но ведь наследование это плохо)

но ведь наследование это плохо)

Наследование плохо? С каких пор?)) с тех под как появился реакт, golang и редукс? просто готовить его мало кто научился и вернулись назад...

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

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

В программировании практически нет однозначно плохих вещей. Даже goto где-то хорош.

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

В большинстве случаев, но не во всех.

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

есть штук 5 компонентов которые используют наследование

Например можно внести дополнительную функциональность по работе со стейтом в statefull компонент реакта.

И тут либо миксины, либо наследование.

почему?

И по моему мнению наследование здесь лучше подойдёт.

почему?

Потому что надо запихать дополнительные функции в компонент.

я к тому, что эта проблема так же решается композицией

без каких-либо проблем

Как?

например

Блин, это не то, здесь добавляется дополнительная хрень в props. Я вообще про другое.

Я говорю о добавлении методов для работы со стейтом компонента. Через пропсы такое прокидывать глупо.

Это как раз тот редкий случай для применения наследования компонент.

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

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

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

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

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

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

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

извините

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

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

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

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

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

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

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

либо cb либо then

then лутше

да вроде к каждому методу дописано 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 поможет в скорости?

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

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

Ооо, это да))

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

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

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