Blog by Fi1osof

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

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

Восстановление поиска и постраничности в в топиках на сайте Клуба

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

MODX-Клуб превращается в фриланс-биржу

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

Улучшенный каталог сайтов

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

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

Оригинальный интернет-каталог на MODX+node.js+react.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 работать 

Да, так гораздо удобнее.

Только вот такой момент - статья "React-js. Урок №1. Быстрый старт." получилась уж очень объемной, и в списке статей не очень удобно прокручивать так далеко. Мне кажется, в списке стоит ограничивать выводимый объём, и выводить тот же экспандер. ИМХО так удобнее будет.

Да, так гораздо удобнее. Только вот такой момент - статья "React-js. Урок №1. Быстрый старт." получилась уж очень объемной, и в списке статей не очень удобно прокручивать так далеко. Мне кажется, в списке стоит ограничивать выводимый объём, и выводить тот же экспандер. ИМХО так удобнее будет.

Да, так гораздо удобнее. Только вот такой момент -

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

Поиск - это несомненно хорошо. Но так как результа

> Мне кажется, в списке стоит ограничивать выводимый объём, и выводить тот же экспандер. ИМХО так удобнее будет.

Не все так просто. Но я подумаю об этом.

> Мне кажется, в списке стоит ограничивать выводимый объём, и выводить тот же экспандер. ИМХО так удобнее будет. Не все так просто. Но я подумаю об этом.

> Мне кажется, в списке стоит ограничивать выводим

Попозже доработаю довольно подробный поиск.

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

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

Здорово, давно ждал этого функционала

Действительно здорово.  Несколько дней, а столько новшеств. То ли еще будет :)

Действительно здорово.  Несколько дней, а столько новшеств. То ли еще будет :) В предвкушении...

Действительно здорово.  Несколько дней, а столько 

Это всё сила React

Николай, это очень крутой функционал! Ждем уроков по react+modx!

Николай, это очень крутой функционал! Ждем уроков 

Такой вопрос... Насколько я знаю, у вас react работает с процессорами getdata и т.д. Насколько целесообразной была бы интеграция restful api? 

Такой вопрос... Насколько я знаю, у вас react рабо

Честно сказать, я не очень понимаю что такое RESTful. Прочитал в вики, но все равно не нашел четких критериев что есть что. Но судя по всему, здесь именно так и используется. Интерфейсы-то изоморфные. MODX здесь является по сути сервером, никак не влияющим на отрисовку HTML. Он только отдает данные в JSON. Даже на стороне сервера, там крутится node.js, а Реакт-приложения получаются данные в JSON.

Честно сказать, я не очень понимаю что такое RESTf

Рад бы обратную связь дать, но работы добавлял не лично, всех нюансов не видел :)

Рад бы обратную связь дать, но работы добавлял не 

Ну, теперь они у тебя в профиле есть)

Осталось только добавить пакеты в репо :)

К слову: сделай отправку комментария по Ctrl+Enter.

Осталось только добавить пакеты в репо :) К слову: сделай отправку комментария по Ctrl+Enter.

Осталось только добавить пакеты в репо :) К слову:

Добавил Ctrl+Enter

Сайт улучшается прямо на глазах )

Вы еще не все видите :) Там под капотом столько всего делается... Прям реально очень много. Сейчас вот еще раздел Комментарии появится (хотя меню итак уже заметно выросло). Сейчас вот еще виртуализацию DOM на стороне сервера победил, и теперь вообще все рендерится на сервере, то есть JS в браузере можно отключить и почти не заметить разницы. Поисковики будут в восторге! :)

Вы еще не все видите :) Там под капотом столько вс

Не забывай в процессе статьи писать, а то начало было многообещающим. Ждем продолжения! ;)

Не забывай в процессе статьи писать, а то начало б

Блин, я скоро спать перестану)) Времени нет на это удовольствие) И на улицу ходить перестану. 

Но ничего, скоро скорректирую график и начну писать свежие уроки.

Блин, я скоро спать перестану)) Времени нет на это удовольствие) И на улицу ходить перестану. Но ничего, скоро скорректирую график и начну писать свежие уроки.

Блин, я скоро спать перестану)) Времени нет на это

Звучит радостно! Набираемся терпения и ждем ))

Собственно видим как на наших глазах рождаются инновации в деле сайтостроительства с помощью в т.ч. 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(). Пока я не увидел для себя замену этому.

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

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

На самом деле, на первый взгляд реакт действительн

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

Сложно конечно решать задачи такого рода без вебпа

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

Тут ставка делалась на простоту установки в MODX. 

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

Роман, без server-side rendering это все будет сов

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

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

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