Николай, я лично не вижу ничего ужасного в использовании SCU(shouldComponentUpdate)....и даже больше, считаю что его необходимо использовать для предотвращения многочисленных рендеров и сравнения виртуалДома... Использование стрелочных компонентов также в любом случае заставляет реакт сравнить новый дом с виртуальным...имхо любой компонент не требуется рендерить тогда, когда это не надо для этого компонента.

Артем Гончарук getInitialState не для этого....зачастую требуется сбросить стэйт у компонентов, и вызов this.setState(this.getInitialState()) не мутирует текущий стэйт а заменит его полностью первоначальным

отпадает необходимость писать хоть какое-либо межкомпонентное взаимодействие Забыл сказать. Многие базовые методы и свойства, которые нужны в распределенных компонентах, я вообще переношу в контексты. Вот уж точно сильная штука. Хотя фейсбук не рекомендует использовать контексты и грозятся, что в будущем они исчезнут, я сомневаюсь, что они просто так дадут какую-то замену этому. Слишком многое на этом работает.

Еще хотел бы добавить свое мнение на тему обмена данными между компонентами. Я позже напишу довольно комплексную статью что и как я использую. Но скорее всего это будет после еще нескольких статей про реакт, так как многие просто не моймут о чем речь. Но коротко расскажу что у меня и как. Во-первых, как я и говорил, я не использую редукс. Пара основных причин: 1. Не копал очень глубоко, но мое предположение, что он использует что-то типа [а-ля lodash].cloneDeep, скорее всего для того, чтобы иметь разницу состояний, чтобы можно было потом эту разницу отловиться в методах типа componentWillReceiveProps. Из-за этого я наблюдал кучу тормозов в своих интерфейсах, для устранения которых приходилось исхищряться с методами типаshouldComponentUpdate. 2. Мне не нравится эта децинтрализованность в описании редюсеров и экценов. В итоге я перешел на flux (который как раз и использует immutablejs). Но и его я чуть под себя модифицировал. Теперь у меня примерно такие конструкции используются: Как видно, тот пляшешь от одного исходного объекта store. И это я еще оптимизирую, чтобы вовсе было store.reduce("UPDATE", item, data); Такие действия не вызывают изменений в стейтах и пропсах, но в нужных компонентах просто подписываешься на диспетчер через store.getDispatch().register и все, там уже сам решаешь когда что принимать и что с этим делать. Есть несколько преимуществ в этом. 1. Самое главное: я в хранилищах могу хранить реальные действующие объекты и в дальнейшем обновлять их как напрямую (если очень хочется), так и находить их с помощью соответствия имеющегося объекта. Пример: Мне не нужно в таком случае никаких идентификаторов. Именно это позволяет создавать сразу несколько временных объектов, даже пустых, а потом нелинейно их редактировать. 2. Производительность. Из-за отсутствия каких-либо операций копирования, даже множественные обходы не дают какой-то ощутимой нагрузки.

Беглый взгляд говорит, что вот эта конструкция описанная в статье: window.FrontBasketTemplates = FrontBasketTemplates; вызовет падение ноды при серверном рендеринге, поскольку в глобал скойпе не будет window :-). Да, так и есть, упадет :) К слову, совсем недавно воевал здесь же с редактором draft-js, мне на сервере надо было генерить стейт методом convertFromHTML, так вот ему нужен DOM:) Помог domjs, очень крутая штука :) Но если бы у меня был ssr, нафиг я бы вообще заморочился с жучкой?))) Это эксперимент был. Хотя думаю, что-то из этого все-таки выкатит, есть у меня пара идей.

Еще хотел бы добавить свое мнение на тему обмена данными между компонентами. Если использовать единый стор, отпадает необходимость писать хоть какое-либо межкомпонентное взаимодействие, по сути его и не должно быть, это противоречит компонентному подходу, компонент не должен знать о том, что есть кто-то еще, он должен получать данные, отрисовываться и если нужно выполнять какую-то свою логику. В едином сторе лежат данные которые мы можем получать прикручивая компоненты к тем или иным узлам стора, тогда в большенстве случаев и потребность в жизненном цикле отпадает и компоненты становятся стрелочными, работают быстрее и проверяют сами нужно ли им отрисовываться по пропсам. Да кстати рекомендую использовать immutablejs и хранить данные в таком представлении, тогда проверка необходимости рендеринга работает лучше, соответственно все приложение работает быстрей.

а лучше вообще в конструкторе this.state = this.getInitialState() а getInitialState возвращает объект :) я почему-то приучился так делать) getInitialState более не используется, это для ES5 варианта было на старых версиях react ). Достаточно просто присвоить объект к this.state как в предыдущем комментарии у Николая :-). В документации на фейсбук много примеров :-). > Не хватало еще API для запросов. Я использую redux и smart actions в которых делаю запросы в graphQL, результат новым экшном кладу в store. Вообще можно использовать redux saga, она использует генераторы по сути делает тоже самое, но с разницей, экшны у саги должны быть тупые :-). Мы с товарищем на одном проекте на react-native используем сагу, на том, что с модх соединяли без саги, есть просто экшны которые диспатчатся при входе на определенный локейшн, в них делается запрос и результат кладется в store, далее каскадный апдейт автоматом происходит. Грубо говоря у каждого могуля (страницы) есть свой экшн входа который активируется при монтировании модуля, активируется роутером, а GraphQL позволяет одним запросом получить все необходимые данные для всех компонентов сразу, ну и за счет асинхронности (nodejs имплементация) внутри самого GraphQL часть запросов может выполняться параллельно, через несколько коннекшнов к базе, что повышает производительность. > Кстати, что думаете на счет этого эксперимента-костыля Думаю, прекрасно, что сообщество в целом наконец стало интересоваться данной технологией и массово ее использовать :-). Я пока внимательно не знакомился с трудом, если желаете могу позже оставить свое мнение. Беглый взгляд говорит, что вот эта конструкция описанная в статье: window.FrontBasketTemplates = FrontBasketTemplates; вызовет падение ноды при серверном рендеринге, поскольку в глобал скойпе не будет window :-).

Почитал про GraphQL поподробней. Да, очень интересная штука. В самое ближайшее время поковыряю. Уже есть несколько идей интересных. Вообще, сначала я освоил react. Затем flux, и был очень рад! Локальных стейтов и пропсов было мало, и не хватало более функциональных хранилищ. На самом деле еще redux освоил, но остановился на флюксе по ряду причин. Но это все на клиенте (состояния и отображения). Не хватало еще API для запросов. И вот чувствую, что мое счастье близко :)

а лучше вообще в конструкторе this.state = this.getInitialState() а getInitialState возвращает объект :) я почему-то приучился так делать) PS Артем Гончарук, интересно посмотреть на ваш вариант...именно так мне и думалось объединение реакта с modx

Кстати, что думаете на счет этого эксперимента-костыля? https://modxclub.ru/topics/eksperiment.-korzina-dlya-minishop2-na-reakte-2689.html