Я вижу Вы поправили и сделали state static свойством. Так не будет работать :-). Это именно свойство объекта, а static это свойство класса Вы объявили и внутри объекта оно будет доступно через this.constructor . Ага, не будет так работать :) Короче спал мало, и запутался с этим пропсами, стейтами, контекстами и т.п. :) Короче, вот так работает:

Согласитесь, если это засунуть в constructor, не получится их так дернуть Ну state это пропс объекта, но не пропс класса :-). Пропс класса конечно в конструкторе добавлять не нужно :-). Там тоже есть варианты в соответствии с тем как у Вас babel настроен :-). Вообще это же JavaScript можно еще много как писать, просто я указал на вариант ближе к спецификации ecma 2015 ( http://2ality.com/2015/02/es6-classes-final.html ). На мой взгляд, если мы все будем придерживаться правил, код станет более дружественным :-). Но я конечно же не против, просто свое мнение высказал :-). В общем-то тоже самое и я о Modx думаю, поэтому очень не нравится отсутствие каких либо движений со стороны сообщества в этом направлении ))). > GraphQL у меня пока еще только на очереди Можно разруливать по безопасности сделав взаимодействие с modx в resolve методах или middleware накрутить, можно еще вариантов напридумывать :-). В любом случае очень рекомендую, крайне удобный инструмент!!! Однако ближайшие проекты буду делать в такой связке, все достаточно не плохо вышло, несмотря на минусы которые я вижу :-). Я вижу Вы поправили и сделали state static свойством. Так не будет работать :-). Это именно свойство объекта, а static это свойство класса Вы объявили и внутри объекта оно будет доступно через this.constructor . > И если там же выполнить команды $r.state.open = true (то есть установить новое значение состояния) и потом выполнить $r.forceUpdate() Лучше просто $r.setState({ open: true }); оно обновит значение состояния и сразу приведет к автоматическому перерендеру, без форса ). Ребята из фейсбука не рекомендуют forceUpdate использовать :-)

Роман, без server-side rendering это все будет совсем не то, многим это по SEO ударит. А если на стороне сервера еще средствами MODX прорисовывать, то будет задвоение шаблонизации и двойная нагрузка. Это все только усложнит проект. В общем пока нет ни в чем уверенности. Время покажет.

Тут ставка делалась на простоту установки в MODX. А так - я тоже согласен, с webpack гораздо гораздее получается

Сложно конечно решать задачи такого рода без вебпака....но я я все же попробую предложить свои мысли по этому поводу снова: а стоит ли отказываться от него вообще? от вебпака? Что мешает нам делать все в "правильном" виде? мне видится все же один базовый компонент реакта(ядро) и много асинхронных модулей к нему, которые подгружаться будут динамично - лучший вариант....базовый компонент(ядро) работает с бэкендом(modx), загружает к примеру список модулей, его зависимостей, чанки(шаблоны), а также обеспечивает взаимодействие модулей с бэкендом(процессором modx)....получается все наши маленькие модули, будь то для вывода корзины или постов, будут "тупыми" и будут взаимодействовать только с ядром(основным модулем реакта)....я уверен что такой подход изначально избавит от множества головняка в будущем. И возможностей при таком подходе может быть больше: к примеру модуль для вывода целиком страницы, модуль для авторизации, модуль для модальных окон....к тому же позволил бы избавиться от множества jquery кода

На самом деле, на первый взгляд реакт действительно кажется слишком перенавороченным (зачем рисовать html через js?!), но когда начинаешь решать задачи чуть сложнее отправки формы обратной связи, понимаешь, что это сильно упрощает жизнь. И даже и с такой формой программирование валидации упрощается в разы.

По поводу остального не буду спорить, у каждого свое видение. Скажу только от себя, почему я еще буду пока использовать MODX. GraphQL у меня пока еще только на очереди, надо будет выделить время на его освоение обязательно, но я не знаю что у него с политиками безопасности. Если бы вопрос просто стоял в формировании запросов, я вполне мог бы заюзать тот же knex и не париться. Но вопрос же еще в политиках безопасности. Далеко ходить не надо, здесь же есть закрытые блоги с различными уровнями доступа как минимум. То есть активно используется $modx->hasPermission(). Пока я не увидел для себя замену этому.

Хотел бы один момент отметить, вот так объявлять state неправильно: На самом деле это не мой код, а как я и писал выше, это официальный пример :) https://github.com/callemall/material-ui/blob/v1.0.0-beta.6/docs/src/pages/demos/snackbars/SimpleSnackbar.js#L19 Но вам плюс, что вы заметили. Хотя правильно не только так, как вы сказали. Вполне достаточно прописать static state. Я вам более скажу, можно вот так: Это я расширяю свойства по умолчанию, полученные от базового класса, можно так же и стейты расширять. Согласитесь, если это засунуть в constructor, не получится их так дернуть, пока он не инициализирован. Здесь просто надо изначально ориентироваться, какие свойства и состояния будут требовать инициализации объекта, а какие нет. А так это синтаксический сахар, выполнение одной и той же задачи с одним и тем же результатом, просто по-разному. А официальная документация реакта, как хорошо заметили на хабре - написана как поток сознания :) Там не все показано.

И да, соглашусь с мнением выше, Modx к сожалению сильно устарел, несмотря на то, что работы над ним ведутся достаточно активно. Под капот заглядываешь и плакать хочется... Что касается менеджера, тоже соглашусь, ExtJS сам по себе весьма плох, старая версия все сильно усугубляет. Весь фреймворк в целом требует полной переработки на мой взгляд и с точки зрения архитектуры и с точки зрения реализации. Время идет, давно появились PSR стандарты, замечательная вещь, просто необходимая я считаю как для универсальности интерфейсов и разных механизмов так и для повышения культуры кода. Если кто не смотрит, загляните в расширения, кровь из глаз... Такое нельзя на свет выпускать :-). Сам давно использую Modx, не думайте, я не тролю, просто печально, что проект так отстал, а в свете данной статьи этот контраст настолько силен, что люди выше задаются вопросом как одно с другим совместить ))). Из моего сообщения выше видно что в принципе никак ))). GraphQL читает данные напрямую из базы данных, доступность таблиц / полей и отношения между ними описывается в его моделях, по сути весь фронт вместе с бэком для фронта о Modx вообще не знает :-), а все потому, что Modx слишком устарел... В любом случае автору за статью спасибо. Хотел бы один момент отметить, вот так объявлять state неправильно: Правильно в конструкторе: Вот пример в доке:

Здравствуйте. Все о теории да о теории, а я скажу, буквально сейчас соединил одно с другим. Могу сказать по опыту, все вполне "склеивается" если знать как :-). У меня получился следующий стек: ReactJS + NodeJS + GraphQL + Modx. ServerSide Rendering на Node выполняет изоморфный бандл который выполняется после и на клиенте. Rest у Modx просто ужасный, да и вообще сам Rest уже отмирающий способ взаимодействия с сервером, я использую GraphQL для получения данных в клиентском приложении (ну и в SSR, один и тот же бандл ведь), Modx только как админка. Для корректного рендеринга компонентов используя MigX + Custom TV накидал сборку контентной части так же компонентами, в клиент уходит JSON со списком компонентов и данными к ним. В общем получилось вполне не плохо, использовал Modx так как много подходящих наработок было. ExtJS просто катастрофа, я бы его сжег, в остальном все вполне собралось и заработало :-).