Эксперименты и исследования

Blog by Fi1osof

Современный сайт на javascript.

React-js. Урок №1. Быстрый старт.

Улучшенный поиск на сайте Клуба

Собственное портфолио на сайте MODX-Клуба

Эксперимент. Корзина для minishop2 на реакте.

React-js. Урок №2. Запросы с помощью GraphQL

Оригинальный интернет-каталог на MODX+node.js+react.js

ShopModxBox-4.0 by React-JS

ShopModxBox-4.2.0

Расширение API-запросов в ShopModxBox

ShopModxBox-4.3.0

Graphcool Prisma. Добавляем авторизацию.

Измененная версия modxclub.ru на prisma-cms, пока что еще в связке с MODX

revolution & react

Я так понимаю, на сервере должен node.js работать?

Да. На гитхабе как раз лежит пара модулей. Один из них — веб-сервер для node.js

Да. На гитхабе как раз лежит пара модулей. Один из

Понятно

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

круто, отлично!
 а как результаты, где можно демо 

Демо специально я нигде не публиковал. Так что только самому запускать и разворачивать. Пример шаблона есть в самом модуле.

Демо специально я нигде не публиковал. Так что тол

Не путать с «я специально демо нигде не публиковал». Смысл совсем другой: )

Не путать с «я специально демо нигде не публиковал

Николай, это круто! Что почитать, чтобы делать такие сайты?)

Николай, это круто! Что почитать, чтобы делать так

Читать на самом деле много. webpack, react, material-ui, чистый javascript и т.п. Скоро начну цикл статей по этому направлению.

Читать на самом деле много. webpack, react, materi

Здравствуйте Николай. Смотрю вы выбрали react.js, а Angular 2 не рассматривали? Я думаю за такими сайтами (веб-приложениями) будущее, поэтому тоже планирую изучить данные технологии. Я конечно еще совсем "зеленый" "программист", но учиться никогда не поздно. Жду ваших статей на эту тему, они у вас всегда понятные и полезные.

Здравствуйте Николай. Смотрю вы выбрали react.js, 

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

Angular - готовый фреймворк, а я все-таки любитель

Идею понял, спасибо.

Не за что

Бомба) Только вот один момент смущает - как поисковики будут индексировать такой сайт?

Бомба) Только вот один момент смущает - как поиско

А вы посмотрите внимательней на сам сайт MODX-Клуба. Он и без JS рендерится, на стороне сервера. Работает node.js+react-dom. Все отлично индексируется. Тройка тоже чуть позже заработает на такой связке.

А вы посмотрите внимательней на сам сайт MODX-Клуб

Хорошо, косяк в тройке, работает только на ie 11 на ниже нет, ошибка в консоле.

Хорошо, косяк в тройке, работает только на ie 11 н

Полифилы потом добавлю. А вообще IE - это косяк)

Здорово! Очень быстро работает!  

.block_title .searchform input {padding:0px 20px 0px 60px}

Здорово! Очень быстро работает!

P.S. верстка не наша, наше только программирование. Верстка предоставлялась заказчиком. Мы ее как есть переносили на JSX.

@msk13s, привет! Спасибо) P.S. верстка не наша, наше только программирование. Верстка предоставлялась заказчиком. Мы ее как есть переносили на JSX.

@msk13s, привет! Спасибо) P.S. верстка не наша, на

Очень и очень впечатляет! Как будто прикасаешься к будущему веб-технологий! Безусловное и нужное направление, радует что эти современные технологии внедряете и нас учите! Спасибо за информирование!

Очень и очень впечатляет! Как будто прикасаешься к

Супер, трендовая тема! 

Вопрос: Насколько хорошая поддержка браузерами  react без  node.js ?

Супер, трендовая тема! Вопрос: Насколько хорошая поддержка браузерами  react без  node.js ?

Супер, трендовая тема! Вопрос: Насколько хорошая п

MODX+node.js+react сомневаюсь что в таком стэке получится организовать корректный serverside rendering  + code splitting, разве что modx будет в роли REST сервиса, в который будет стучаться node.js, но это оверхед...не говоря уже о том, что разрабатывая приложения на реакте прикручивать к нему тяжелую "админку" modx для управления ресурсами - крайне гиблое тяжело поддерживаемое дело...хотя я всей душой люблю реакт и modx

MODX+node.js+react сомневаюсь что в таком стэке по

> Вопрос: Насколько хорошая поддержка браузерами  react без  node.js ?

Это не связанные друг с другом вещи. Реакт работает сам по себе. Нода нужна только для сборки конечного кода, если мы модульно все собираем. А так браузер вообще не знает есть там нода или нет.

Но предполагаю, что ваш вопрос про то, есть ли разница когда конечный HTML отрисован на стороне сервера, а когда нет. Тут браузеру опять-таки фиолетово. Даже если код отрисован, все равно после загрузки должен реакт сработать, и если что-то не так, страница будет статической, реакт работать не будет.

> Вопрос: Насколько хорошая поддержка браузерами  react без  node.js ? Это не связанные друг с другом вещи. Реакт работает сам по себе. Нода нужна только для сборки конечного кода, если мы модульно все собираем. А так браузер вообще не знает есть там нода или нет. Но предполагаю, что ваш вопрос про то, есть ли разница когда конечный HTML отрисован на стороне сервера, а когда нет. Тут браузеру опять-таки фиолетово. Даже если код отрисован, все равно после загрузки должен реакт сработать, и если что-то не так, страница будет статической, реакт работать не будет.

> Вопрос: Насколько хорошая поддержка браузерами  

> MODX+node.js+react сомневаюсь что в таком стэке получится организовать корректный serverside rendering  + code splitting, разве что modx будет в роли REST сервиса, в который будет стучаться node.js, но это оверхед

Посмотрите на сайт Клуба. Все работает замечательно.

> MODX+node.js+react сомневаюсь что в таком стэке получится организовать корректный serverside rendering  + code splitting, разве что modx будет в роли REST сервиса, в который будет стучаться node.js, но это оверхед Посмотрите на сайт Клуба. Все работает замечательно.

> MODX+node.js+react сомневаюсь что в таком стэке 

> Посмотрите на сайт Клуба. Все работает замечательно. 

не вижу никакого code splitting на сайте клуба и async components, у вас кстати на продакшен бандле висит logger и в консоль кидает экшены пользователям...роутинг у вас на клиенте и сообщает ноде о смене VIEW, вы стучитесь в тяжеленный modx, который стучится в одну таблицу для получения документа, подгрузки всех связанных и необходимых TV полей за один запрос...все хорошо работает пока у вас в сторе несколько сущностей, а если их будет сотня...а что с подходом в целом?  у вас доп запросы все идут к одному коннектору, что противоречит в принципе архитектуре REST с его endpoint'ами...зачем использовать то что принадлежит веб-приложениям, если не соблюдать базовые принципы построения веб-приложений...в целом конечно труд достойный, но все же сизифов труд.

> Посмотрите на сайт Клуба. Все работает замечательно. не вижу никакого code splitting на сайте клуба и async components, у вас кстати на продакшен бандле висит logger и в консоль кидает экшены пользователям...роутинг у вас на клиенте и сообщает ноде о смене VIEW, вы стучитесь в тяжеленный modx, который стучится в одну таблицу для получения документа, подгрузки всех связанных и необходимых TV полей за один запрос...все хорошо работает пока у вас в сторе несколько сущностей, а если их будет сотня...а что с подходом в целом?  у вас доп запросы все идут к одному коннектору, что противоречит в принципе архитектуре REST с его endpoint'ами...зачем использовать то что принадлежит веб-приложениям, если не соблюдать базовые принципы построения веб-приложений...в целом конечно труд достойный, но все же сизифов труд.

> Посмотрите на сайт Клуба. Все работает замечател

Николай, здравствуйте. Обязательно буду следить за вашим курсом и по возможности повторять описанное. Меня тоже заинтересовал момент про modx+node.js+react. А какая здесь роль отведена модексу? На сколько мне известно node.js вполне покрывает потребности бэкенда. Модекс только ради админки, чтобы свою не пилить или на него еще какие-то функции возлагаются?

Николай, здравствуйте. Обязательно буду следить за

Нахожу этот курс очень полезным и интересным, Николай.  Буду ждать следующих уроков и проходить этот. 

Нахожу этот курс очень полезным и интересным, Нико

> сомневаюсь что в таком стэке получится организовать корректный serverside rendering  + code splitting

> не вижу никакого code splitting на сайте клуба и async components

code splitting я не докручивал, необходимости не было у меня. А вот serverside rendering работает. 

> у вас кстати на продакшен бандле висит logger и в консоль кидает экшены пользователям...

И пусть кидает. Он мне здесь для отладки, я же многое здесь в первую очередь экспериментирую.

> роутинг у вас на клиенте

Не правда. На сайте Клуба роутинг на стороне сервера. С компонентами некоторая заморочка имеется, но роутинг MODX обрабатывает.

Про REST и т.п. - мне в данном случае удобней было именно так делать. 

В целом, если вы знаете как все это делать лучше: велкам, можете так же написать свои статьи. Иначе, без подробного туториала, вряд ли получится понять что именно вы имеете ввиду и в чем разница. Принцип: возражаешь - предлагай.

> сомневаюсь что в таком стэке получится организовать корректный serverside rendering  + code splitting > не вижу никакого code splitting на сайте клуба и async components code splitting я не докручивал, необходимости не было у меня. А вот serverside rendering работает. > у вас кстати на продакшен бандле висит logger и в консоль кидает экшены пользователям... И пусть кидает. Он мне здесь для отладки, я же многое здесь в первую очередь экспериментирую. > роутинг у вас на клиенте Не правда. На сайте Клуба роутинг на стороне сервера. С компонентами некоторая заморочка имеется, но роутинг MODX обрабатывает. Про REST и т.п. - мне в данном случае удобней было именно так делать. В целом, если вы знаете как все это делать лучше: велкам, можете так же написать свои статьи. Иначе, без подробного туториала, вряд ли получится понять что именно вы имеете ввиду и в чем разница. Принцип: возражаешь - предлагай.

> сомневаюсь что в таком стэке получится организов

> А какая здесь роль отведена модексу? .... Модекс только ради админки, чтобы свою не пилить или на него еще какие-то функции возлагаются?

Да, типа того. Ведь MODX это и политики безопасности, и плагины всякие, и модель базы данных и т.д. и т.п. Вот представь, у тебя задача посадить имеющийся MODX-сайт на эти технологии. Что, переписывать весь сайт с нуля на JS? А пользователи? А заказы? А плагины и т.п.? Нет, очень сомнительная затея. Как мне видится, здесь реакт и т.п. именно идет как фронт для MODX-а, а не полная альтернатива ему.

> А какая здесь роль отведена модексу? .... Модекс только ради админки, чтобы свою не пилить или на него еще какие-то функции возлагаются? Да, типа того. Ведь MODX это и политики безопасности, и плагины всякие, и модель базы данных и т.д. и т.п. Вот представь, у тебя задача посадить имеющийся MODX-сайт на эти технологии. Что, переписывать весь сайт с нуля на JS? А пользователи? А заказы? А плагины и т.п.? Нет, очень сомнительная затея. Как мне видится, здесь реакт и т.п. именно идет как фронт для MODX-а, а не полная альтернатива ему.

> А какая здесь роль отведена модексу? .... Модекс

> Да, типа того. Ведь MODX это и политики безопасности, и плагины всякие, и модель базы данных и т.д. и т.п. Вот представь, у тебя задача посадить имеющийся MODX-сайт на эти технологии. Что, переписывать весь сайт с нуля на JS? А пользователи? А заказы? А плагины и т.п.? Нет, очень сомнительная затея. Как мне видится, здесь реакт и т.п. именно идет как фронт для MODX-а, а не полная альтернатива ему.

Вот именно по этой причине это и есть достойный труд! Подружить бы идеологию modx с реактом с учетом всех архитектурных стандартов - это будет мощнейший комбайн на длительный срок, бомба!!! еще бы админка modx на реакте была!)))

> Да, типа того. Ведь MODX это и политики безопасности, и плагины всякие, и модель базы данных и т.д. и т.п. Вот представь, у тебя задача посадить имеющийся MODX-сайт на эти технологии. Что, переписывать весь сайт с нуля на JS? А пользователи? А заказы? А плагины и т.п.? Нет, очень сомнительная затея. Как мне видится, здесь реакт и т.п. именно идет как фронт для MODX-а, а не полная альтернатива ему. Вот именно по этой причине это и есть достойный труд! Подружить бы идеологию modx с реактом с учетом всех архитектурных стандартов - это будет мощнейший комбайн на длительный срок, бомба!!! еще бы админка modx на реакте была!)))

> Да, типа того. Ведь MODX это и политики безопасн

> Да, типа того. Ведь MODX это и политики безопасности, и плагины всякие, и модель базы данных и т.д. и т.п.

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

Еще было бы классно, если бы вы описали такие моменты в этой связке:

1. MODX (или php) какую роль в приложении выполняет часть написанная на php

2. Какую роль выполняет часть написанная на Node.js

3. С react'ом более менее ясно, но не очень понятно как он взаимодействует с MODX или php и Node.js

4. Как все это дело взаимодействует в куче и почему именно эти технологии.

> Да, типа того. Ведь MODX это и политики безопасности, и плагины всякие, и модель базы данных и т.д. и т.п. Ну я так и подумал сразу такой себе "хак" для того, чтобы с нуля меньше писать, а тут все-таки "технология отработана", но и предположил, что возможно еще есть какие-то причины. Просто тут некий диссонанс возникает — фронт летает как ракета и "тяжеленная" админка модекса, но это уже мои личные заморочки. Еще было бы классно, если бы вы описали такие моменты в этой связке: 1. MODX (или php) какую роль в приложении выполняет часть написанная на php 2. Какую роль выполняет часть написанная на Node.js 3. С react'ом более менее ясно, но не очень понятно как он взаимодействует с MODX или php и Node.js 4. Как все это дело взаимодействует в куче и почему именно эти технологии.

> это будет мощнейший комбайн на длительный срок, бомба!!!

Именно так. Я считаю, что даже если сейчас MODX в развитии сам по себе встанет колом, за счет примеси этих современных технологий можно легко рассчитывать еще минимум на 2-3 года актуальности.

> еще бы админка modx на реакте была!)))

Я думаю над этим, и некоторые наработки у меня уже есть.

> это будет мощнейший комбайн на длительный срок, бомба!!! Именно так. Я считаю, что даже если сейчас MODX в развитии сам по себе встанет колом, за счет примеси этих современных технологий можно легко рассчитывать еще минимум на 2-3 года актуальности. > еще бы админка modx на реакте была!))) Я думаю над этим, и некоторые наработки у меня уже есть.

> это будет мощнейший комбайн на длительный срок, 

> Просто тут некий диссонанс возникает — фронт летает как ракета и "тяжеленная" админка модекса, но это уже мои личные заморочки.

На скорость смотреть не совсем правильно. Лично для меня реакт - это в первую очередь более удобная среда разработки. MODX был и есть без как такового фронта, каждый крутит свое на что горазд (кто чистый HTML+CSS фигачит, кто LESS-SASS примешивает и собирает by MinifyX), кто готовые темы как может прикручивает. Так что проблема фронта для MODX всегда актуальна была. Я не решаю эту проблему, но мне с этим работать удобней и перспективней. Ведь на выходе получаются веб-приложения, которые могут работать не только с MODX.

Все остальное будет описано позже. Вот это вводная статья, самый минимум. А какой объем получился? Чтобы описать даже начальный уровень, придется написать еще минимум десяток таких статей, а то и не один. В дальнейшем последовательно мы все вопросы эти разберем.

> Просто тут некий диссонанс возникает — фронт летает как ракета и "тяжеленная" админка модекса, но это уже мои личные заморочки. На скорость смотреть не совсем правильно. Лично для меня реакт - это в первую очередь более удобная среда разработки. MODX был и есть без как такового фронта, каждый крутит свое на что горазд (кто чистый HTML+CSS фигачит, кто LESS-SASS примешивает и собирает by MinifyX), кто готовые темы как может прикручивает. Так что проблема фронта для MODX всегда актуальна была. Я не решаю эту проблему, но мне с этим работать удобней и перспективней. Ведь на выходе получаются веб-приложения, которые могут работать не только с MODX. Все остальное будет описано позже. Вот это вводная статья, самый минимум. А какой объем получился? Чтобы описать даже начальный уровень, придется написать еще минимум десяток таких статей, а то и не один. В дальнейшем последовательно мы все вопросы эти разберем.

> Просто тут некий диссонанс возникает — фронт лет

>  фронт летает как ракета и "тяжеленная" админка модекса, но это уже мои личные заморочки.

это не ваши личные заморочки - это горькая правда...админка modx нуждается в в полной переработке с учетом современных стандартов. там еще и старая версия extjs все усугубляет. PS в комментариях выше описана техника подхода к реализации такого гибридного приложения

> Именно так. Я считаю, что даже если сейчас MODX в развитии сам по себе встанет колом, за счет примеси этих современных технологий можно легко рассчитывать еще минимум на 2-3 года актуальности.

Если мыслить еще глубже и научить modx работать с компонентами, а точнее научить компоненты modx работать c компонентами react - вот это сильно! устанавливаешь один компонент, он вживляется и в modx, имеет асинхронный код компонента для клиента и появившись на странице, динамично загружается - и так со всеми компонентами)) фантазия разыгралась))) я с вами!)

>  фронт летает как ракета и "тяжеленная" админка модекса, но это уже мои личные заморочки. это не ваши личные заморочки - это горькая правда...админка modx нуждается в в полной переработке с учетом современных стандартов. там еще и старая версия extjs все усугубляет. PS в комментариях выше описана техника подхода к реализации такого гибридного приложения > Именно так. Я считаю, что даже если сейчас MODX в развитии сам по себе встанет колом, за счет примеси этих современных технологий можно легко рассчитывать еще минимум на 2-3 года актуальности. Если мыслить еще глубже и научить modx работать с компонентами, а точнее научить компоненты modx работать c компонентами react - вот это сильно! устанавливаешь один компонент, он вживляется и в modx, имеет асинхронный код компонента для клиента и появившись на странице, динамично загружается - и так со всеми компонентами)) фантазия разыгралась))) я с вами!)

>  фронт летает как ракета и "тяжеленная" админка 

> Если мыслить еще глубже и научить modx работать с компонентами, а точнее научить компоненты modx работать c компонентами react - вот это сильно!

Вот это уже точно лишнее будет :)

> Если мыслить еще глубже и научить modx работать с компонентами, а точнее научить компоненты modx работать c компонентами react - вот это сильно! Вот это уже точно лишнее будет :)

> Если мыслить еще глубже и научить modx работать 

Наконец-то дождался обновления интерфейса в сбербанк-онлайн для юриков. Весьма неплохо и юзабельно получилось. И как вы думаете на чем сделано? На реакте))

Наконец-то дождался обновления интерфейса в сберба

Собственно видим как на наших глазах рождаются инновации в деле сайтостроительства с помощью в т.ч. MODX. Хорошие комментарии от всех и отличный урок получился! Ждем продолжения и углубления в тему.

> если не соблюдать базовые принципы построения веб-приложений...в целом конечно труд достойный, но все же сизифов труд.

Также согласен с Николаем в том смысле что: > В целом, если вы знаете как все это делать лучше: велкам, можете так же написать свои статьи.  

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

Уверен на 100% - это начало большого и интересного пути:

>  Я не решаю эту проблему, но мне с этим работать удобней и перспективней. Ведь на выходе получаются веб-приложения, которые могут работать не только с MODX. 

Собственно видим как на наших глазах рождаются инновации в деле сайтостроительства с помощью в т.ч. MODX. Хорошие комментарии от всех и отличный урок получился! Ждем продолжения и углубления в тему. > если не соблюдать базовые принципы построения веб-приложений...в целом конечно труд достойный, но все же сизифов труд. Также согласен с Николаем в том смысле что: > В целом, если вы знаете как все это делать лучше: велкам, можете так же написать свои статьи. Если и вправду есть какие-то неточности или другие взгляды, хотелось бы подробностей в обсуждении и лучше интересных статей в Клубе. Уверен на 100% - это начало большого и интересного пути: >  Я не решаю эту проблему, но мне с этим работать удобней и перспективней. Ведь на выходе получаются веб-приложения, которые могут работать не только с MODX.

Собственно видим как на наших глазах рождаются инн

Ну, на сайте Клуба эти изменения заметны? :)

Здравствуйте. Все о теории да о теории, а я скажу, буквально сейчас соединил одно с другим. Могу сказать по опыту, все вполне "склеивается" если знать как :-). У меня получился следующий стек:

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

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

Здравствуйте. Все о теории да о теории, а я скажу,

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

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

В любом случае автору за статью спасибо. Хотел бы один момент отметить, вот так объявлять state неправильно:

Правильно в конструкторе:

class PositionedSnackbar extends Component {
  state = {
    open: false,
    vertical: null,
    horizontal: null,
  };

class PositionedSnackbar extends Component {
  constructor(props) {
    super(props);
    this.state = {
      open: false,
      vertical: null,
      horizontal: null,
    };
  }

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

И да, соглашусь с мнением выше, Modx к сожалению с

> Хотел бы один момент отметить, вот так объявлять state неправильно:

На самом деле это не мой код, а как я и писал выше, это официальный пример :) https://github.com/callemall/material-ui/blob/v1.0.0-beta.6/docs/src/pages/demos/snackbars/SimpleSnackbar.js#L19 

Но вам плюс, что вы заметили. Хотя правильно не только так, как вы сказали. Вполне достаточно прописать static state. Я вам более скажу, можно вот так:

Это я расширяю свойства по умолчанию, полученные от базового класса, можно так же и стейты расширять. Согласитесь, если это засунуть в constructor, не получится их так дернуть, пока он не инициализирован. Здесь просто надо изначально ориентироваться, какие свойства и состояния будут требовать инициализации объекта, а какие нет. А так это синтаксический сахар, выполнение одной и той же задачи с одним и тем же результатом, просто по-разному. А официальная документация реакта, как хорошо заметили на хабре - написана как поток сознания :) Там не все показано.

import lodash from 'lodash';

import DataView from '../';

let defaultProps = lodash.cloneDeep(DataView.defaultProps);

defaultProps = Object.assign(defaultProps, {
	connector_path: 'deals',
});

export default class DealsDataView extends DataView{
    // ...............
}

DealsDataView.defaultProps = defaultProps;

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

По поводу остального не буду спорить, у каждого св

> Согласитесь, если это засунуть в 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 использовать :-)

> Согласитесь, если это засунуть в 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 использовать :-)

> Согласитесь, если это засунуть в constructor, не

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

Ага, не будет так работать :)  Короче спал мало, и запутался с этим пропсами, стейтами, контекстами и т.п. :) Короче, вот так работает:

export default class PartnersByCategoryBlock extends Component{

	static propTypes = {
	};

	static contextTypes = {
		request: PropTypes.func.isRequired,
	};

	constructor(props){

		super(props);

		this.state = {
			partners: [],
			partnersCategories: [],
			category: null,
		}
	}

	render(){

		return <div>Some content</div>
	}
}

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

>>> Я вижу Вы поправили и сделали state static сво

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

Кстати, что думаете на счет этого эксперимента-кос

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

Артем Гончарук, интересно посмотреть на ваш вариант...именно так мне и думалось объединение реакта с modx

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

а лучше вообще в конструкторе this.state = this.ge

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

Почитал про GraphQL поподробней. Да, очень интерес

> а лучше вообще в конструкторе 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 :-).

> а лучше вообще в конструкторе 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 :-).

> а лучше вообще в конструкторе this.state = this.

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

Еще хотел бы добавить свое мнение на тему обмена д

>> Беглый взгляд говорит, что вот эта конструкция описанная в статье: window.FrontBasketTemplates = FrontBasketTemplates; вызовет падение ноды при серверном рендеринге, поскольку в глобал скойпе не будет window :-).

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

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

>> Беглый взгляд говорит, что вот эта конструкция 

>>> Еще хотел бы добавить свое мнение на тему обмена данными между компонентами.

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

Во-первых, как я и говорил, я не использую редукс. Пара основных причин:

1. Не копал очень глубоко, но мое предположение, что он использует что-то типа [а-ля lodash].cloneDeep, скорее всего для того, чтобы иметь разницу состояний, чтобы можно было потом эту разницу отловиться в методах типа componentWillReceiveProps. Из-за этого я наблюдал кучу тормозов в своих интерфейсах, для устранения которых приходилось исхищряться с методами типаshouldComponentUpdate. 

2. Мне не нравится эта децинтрализованность в описании редюсеров и экценов.

В итоге я перешел на flux (который как раз и использует immutablejs). Но и его я чуть под себя модифицировал. Теперь у меня примерно такие конструкции используются:

Как видно, тот пляшешь от одного исходного объекта store. И это я еще оптимизирую, чтобы вовсе было store.reduce("UPDATE", item, data);

Такие действия не вызывают изменений в стейтах и пропсах, но в нужных компонентах просто подписываешься на диспетчер через store.getDispatch().register и все, там уже сам решаешь когда что принимать и что с этим делать. 

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