Ребят, вопрос такой, какие сущности можно напрямую коннетить к стору редакса? Я так понимаю, что только контейнеры, либо умные компоненты?

Ребят, вопрос такой, какие сущности можно напрямую коннетить к стору редакса? Я так понимаю, что только контейнеры, либо умные компоненты?

тупые компоненты разве нельзя?

Ребят, вопрос такой, какие сущности можно напрямую коннетить к стору редакса? Я так понимаю, что только контейнеры, либо умные компоненты?

oO

Вот вопрос, как это на производительность и семантику влияет, может я заблуждаюсь

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

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

подскажите в чем фишка выносить разметку за компонент?

Гайз, а кто-нить юзает ООП на проектах? Если да, можно узнать, как оно применяется для разработки на реакте. И вообще есть ли смысл?

Я, вот, смысла вообще не вижу. Ни разу н было такого случая, чтобы ООП могло помочь

Но может я один такой?

Что значит ООП в твоей трактовке?

Гайз, а кто-нить юзает ООП на проектах? Если да, можно узнать, как оно применяется для разработки на реакте. И вообще есть ли смысл?

Ну у меня, например, кнопки наследуются от дефолтной, меняется только рендер + добавлются новые методы если нужно.

Наследование. То что в js и называется ООП)

нет, наследование в реакте должно быть только от базовых классов

типа React.Component

нет, наследование в реакте должно быть только от базовых классов

почему?

остальное - на композиции

остальное - на композиции

согласен

Ну у меня, например, кнопки наследуются от дефолтной, меняется только рендер + добавлются новые методы если нужно.

А что там наследуется, если не секрет?

потому что наследование - опасная хрень в условиях кучи лайфцайкл-методов

потому что наследование - опасная хрень в условиях кучи лайфцайкл-методов

Оооо! Вот и аргумент! Спасибо

потому что наследование - опасная хрень в условиях кучи лайфцайкл-методов

Не замечал еще проблем с этим

потому что наследование - опасная хрень в условиях кучи лайфцайкл-методов

мягко говоря спорный аргумент

ну вообще тема "наследование вс композиция" - очень спороемкая

Да вполне себе аргумент, по моему. Таки хрен знает, что у тебя произойдет на willRecieveProps. Передадутся параметры к методу одного типа, когда ожидаются другие. Потом это сложно отследить

Да вполне себе аргумент, по моему. Таки хрен знает, что у тебя произойдет на willRecieveProps. Передадутся параметры к методу одного типа, когда ожидаются другие. Потом это сложно отследить

так говоришь, будто это от подброшенной монетки зависит

с какими пропсами вызовется супер

например

Хотя этот аргумент можно применить к ооп вообще, так что забираю свои слова

дык вообще наследование - отстой:)

и ооп:)

Если не указал в конкретном классе метод, ищется в его прототипе

Тут дорога в одну сторону

вообще, наследование - антипаттерн

оставлю это здесь https://www.youtube.com/watch?v=wfMtDGfHWpA

оставлю это здесь https://www.youtube.com/watch?v=wfMtDGfHWpA

а если лень смотреть, что там в конце?

вообще, наследование - антипаттерн

LOL

а если лень смотреть, что там в конце?

composition over inheritance

а если лень смотреть, что там в конце?

наследование - отстой, юзайте композицию там в конце

LOL

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

вот ещё https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53#.4qef3glib

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

А если у меня два компонента, которые делают одно и то же, но имеют разную верстку, что тогда делать? Дублировать методы для каждого? Или один унаследовать от другого и просто поменять рендер?

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

Да инструмент это, инструмент. Как наследование так и композиция. Правильный инструмент для правильной работы. А не все подряд пихать не глядя.

наследование с умом применять надо

Я наследование в таких случаях использую

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

А что не усложняет? Монады, моноиды, ковариантность, контравариантность? Плохой код можно написать в каком угодно стиле программирования. ИМХО

https://github.com/kreiz0/godota/blob/master/src/components/Search.js

А что не усложняет? Монады, моноиды, ковариантность, контравариантность? Плохой код можно написать в каком угодно стиле программирования. ИМХО

я не спорю

подскажите как фильтровать в редаксе

выходит всегда дизпатчится новый объект

и старое состояние не реально вернуть

необратимые мутации?=)

может в редаксе есть какие то настройки ?

что бы все тот же объект фильтровало

Ты экзамплы редакса читал?

А если у меня два компонента, которые делают одно и то же, но имеют разную верстку, что тогда делать? Дублировать методы для каждого? Или один унаследовать от другого и просто поменять рендер?

в случае реакта можно написать ХОК(hoc) который добавит нужные методы

Ты экзамплы редакса читал?

читал

или написать общий класс для обоих компонентов

может в редаксе есть какие то настройки ?

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

у меня фильтрует

просто баг

если например ввести единицу будет пустой список

просто баг

не баг, а фича

и если ее удалить он будет снова пустой

А ты диспатчишь, когда пустое значение?

и если ее удалить он будет снова пустой

нужен код

https://github.com/kreiz0/godota/blob/master/src/components/Search.js

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

у меня компоненты между собой взаимодействуют по средством этого редакса

я понимаю что оно дизатчит пустой значание

но не знаю как это исправить

каким инструментом

А через когда после moscowjs выдосы обычно появляются?

сохранять ее в переменной, и потом в компонент рендерить эту переменную

@jaybekster насчет moscowjs хз, но обычно месяц-полтора, много времени уходит на монтирование, особенно если записывали/монтировали не профессиональные операторы

нет заглючил) хотел спросить для чего выносить разметку за компонент?

сохранять ее в переменной, и потом в компонент рендерить эту переменную

Потому что при перерендере создавать новый объект через React.createElement дороже, чем если закешировать такой статичный элемент в переменной.

Плагин для бабеля - http://babeljs.io/docs/plugins/transform-react-constant-elements/ делает это за тебя

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

а если он динамичный?

Ну в принципе это имеет смысл если в какой-то момент времени эта штука не так динамична, всмысле например у тебя есть 100 элементов, и для 50 у тебя кусок разметки один, а для 50 другой. Тогда имеет смысл закешировать такой кусок разметки руками (плагин не осилит) по какому-нибудь признаку и выводить. Но! Для более динамичной разметки смысла нет

спасибо)

Ну и вообще, не упарывайся за рендеринг производительность, пока у тебя все это отрабатывает меньше чем 500ms

Кто jest пользовал, хорошая?

Кто jest пользовал, хорошая?

люди в твиттере хвалят

Кто jest пользовал, хорошая?

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

Кто jest пользовал, хорошая?

пользуюсь, для React самое то

Слышал много хвалебных отзывов

Расскажите, кто как тестирует React приложение

jasmine + enzyme в рельсах, пока только начинаем

enzyme + mocha

Ребята, никто не знает как в сафари-инспекторе проинспектировать сам инспектор? Или он не на js написан? Суть в чем - в сафари есть крутая фича подсветки неиспользуемого кода и я хочу просто скопировать и удалить этот неиспользуемый код чтобы разобраться в одной сложной библиотеке но к сожалению через ctrl+c этот код копируется без стилей

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

Мы собираемся просто smoke тесты для начала делать, чтобы понимать, что комплексные компоненты не отваливаются при рефакторинге