Если большой стор, то редакс проседать начинает?

Есть всякие хелперы ж типа редакс-акт

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

Я закидываю в стор объекты вида [ { id:1, data, flag }, { id:2, data } ] и с помощью тривиальных атомарных редюсеров в стор автоматически записываются в форме { ids: [ id1, id2 ], byId: { id1: data, id2: data }, flags: [ id1 ] }

В том же Mobx всякие тривиальные изменения записываются как myState.someField = myBigJsonFromServer и Mobx вызвает перерисовку React

В том же Mobx всякие тривиальные изменения записываются как myState.someField = myBigJsonFromServer и Mobx вызвает перерисовку React

Я про возможности преобразований, а не про то как записывается)

Я про возможности преобразований, а не про то как записывается)

преобразования можно спокойно внести в сеттер

или в функцию/метод

в MobX и Redux/Flux заложены абсолютно противоположные принципы, как их можно сравнивать на уровне имплементации?

А в моём идеальном мире единорогов и бабочек есть такая штука как Object.observe, которая вызывается один раз для корневого объекта стора, и при любом изменении этого самого стора и его полей и полей этих полей и так далее автоматически вызывает туже перерисовку React.

Но увы.

преобразования можно спокойно внести в сеттер

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

https://hackernoon.com/an-artificial-example-where-mobx-really-shines-and-redux-is-not-really-suited-for-it-1a58313c0c70#.wy9nc3r8g

Была статья, что мобкс

А в моём идеальном мире единорогов и бабочек есть такая штука как Object.observe, которая вызывается один раз для корневого объекта стора, и при любом изменении этого самого стора и его полей и полей этих полей и так далее автоматически вызывает туже перерисовку React.

имплементируй и выложи на NPM

То есть по сложным преобразованиям тут единый сеттер как концепция проигрывает

имплементируй и выложи на NPM

костыльно получится

почему же?

То есть по сложным преобразованиям тут единый сеттер как концепция проигрывает

Так функцию же можно написать, да хот тот же редьюсер, если нужно. И в отличии от Redux для всех остальных тривиальных изменений не писать редьюсеры/экшены

Я экшны руками не пишу

почему же?

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

во всём графе объектов

костыльно получится

Простейший Observe имплементируется в 15 строчек

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

Не нужно

Простейший Observe имплементируется в 15 строчек

поделитесь сакральным знанием?

Я же уже говорил, Proxy api

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

кому-то же нужно это делать

Можно перехватывать любые обращения к объекту

Как то - изменение свойств, добавление, удаление, проверка их на существование, и так далее

Тебе просто предоставляют хэндлеры для всего - defineProperty, deleteProperty и т.д.

Можно перехватывать любые обращения к объекту

мне нужно перехватывать не только все обращения к объекту, но и все обращения к тем объектам, которые находятся внутри него

Рекурсия, ещё строчек 30

всё равно костыльно получается, так как нужно оборачивать в прокси все добавления/изменения свойств, плюс с this проблемы возникают

стоп

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

Не возникают

На это Reflect

вы сабжект из rxjs изобретаете?

или мутейшн обзерверс?

(все не читал)

то есть при: const object = { x: 5, change() { this.x = 7; } }; const proxy = new Proxy(object); proxy.change(); будет вызван какой-то хук у прокси?

или мутейшн обзерверс?

вот это вот

ясн

http://caniuse.com/#feat=mutationobserver

http://caniuse.com/#feat=mutationobserver

только не для DOM, а для обычных JS объектов

а, значит rxjs-таки

ясн

rxjs норм

Кто-нибудь, объясните пожалуйста, почему в airbnb style guide советуют использовать для stateless компонентов обычные функции, а не стрелочные? Как вы обычно объявляете stateless компоненты? https://github.com/airbnb/javascript/tree/master/react#class-vs-reactcreateclass-vs-stateless

RusLang.insert('вот оно зло трансляторов - когда пишеш код который не понимаеш как работает','ьь'); << "вот оно зло трансляторов - когда пишешь код который не понимаешь как работает"

Запятая ещё, ага))

Запятая ещё, ага))

Ее в insert не было

Но в грамматике RusLang'a точно описана

Моя либа- мои правила?

Ладно, сделай пул реквест, внесу изменения

Кто-нибудь, объясните пожалуйста, почему в airbnb style guide советуют использовать для stateless компонентов обычные функции, а не стрелочные? Как вы обычно объявляете stateless компоненты? https://github.com/airbnb/javascript/tree/master/react#class-vs-reactcreateclass-vs-stateless

а зачем везде arrow function пихать?)

а зачем везде arrow function пихать?)

Мне они симпатичны, например)

ты из тех, кто бэктики везде пишет?

ты из тех, кто бэктики везде пишет?

Я из тех, кто не знает, что такое бэктики(

а зачем везде arrow function пихать?)

код моднее выглядит

`

`

Да)

require(`react)`

require(`react)`

text = `hello ${world}` ?

тогда все с тобой ясно) любой стайлгайд - набор opinionated решений, выкини то что не нравится, добавь свое)

но вообще судя по всему они юзают функции из-за уже решенной проблемы дебага

тогда все с тобой ясно) любой стайлгайд - набор opinionated решений, выкини то что не нравится, добавь свое)

Мне интересен выбор знающих разработчиков. Почему обычные функции, а не arrow и т.п. Мб я что-то не понимаю)

ERROR: S client not available

там такие же разработчики, как и тут в чате сидят)

// bad (relying on function name inference is discouraged) ну и коммент все поясняет)

Тогда тем более интересно, дабы услышать мнения знающих людей)

// bad (relying on function name inference is discouraged) ну и коммент все поясняет)

Меня этот коммент не убедил, откровенно говоря

ну так да) это уже давно пофиксили. сначала в babel, потом в хроме

Понял)

там не только в .name дело

хотя в основном в этом

бтв хром покажет имя переменной в этом случае вроде

Реактогоспода, поздравляю вас всех с наступающим и желаю вайфай в хату, коддинг в радость, таски в сладость, пальцам ходу, голове приходу, удачи в поиске работы, сто баксов по сдаче(кореша на галеру), ходу ФРОНТЕНДСКОМУ, смерти БЕКЕНДСКОМУ (на самом деле пис)

Реактогоспода, поздравляю вас всех с наступающим и желаю вайфай в хату, коддинг в радость, таски в сладость, пальцам ходу, голове приходу, удачи в поиске работы, сто баксов по сдаче(кореша на галеру), ходу ФРОНТЕНДСКОМУ, смерти БЕКЕНДСКОМУ (на самом деле пис)

Схоронил.

ребята простой вопрос: есть такая структура <main> <one/> <two/> </main> внутри two есть кнопка, по нажатию должен происходить экшн в компоненте one. Торможу, как это сделать красиво? без всяких рефов и вынесений через них нужных функций

Пробрасываешь onButtonClick в two, который меняет значение пропса, прокидываемого в one

в main описываешь фукнцию, которая меняет state main, кидаешь ее в props two и вызывешь. в one по измению props (componentWillReceiveProps) делаешь что надо. если просто переменную в one нужно поменять, то тащишь ее из props

спасибо, поковыряю

или юзай redux, красивее

шеф не разрешает :)

бред)

reflux еще можно

или свой Диспетчер заведи, как у facebook

Кто кстати понял, чем выгоднее PureComponent от обычного?

смотря что называть обычным

ну есть React.Component а щас появился React.PureComponent

ммм, а он не имеет отношения к pure-render-mixin?

имеет

a new base class to extend, replacing react-addons-pure-render-mixin now that mixins don't work with ES2015 classes

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

ну получается PureComponent не перерендеривается, когда перерендериваются родители его, или я что то путаю?

он перерендеривается только если были изменения в его props/state

причём не глубокие изменения, а верхнего уровня