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

Внимание! Сайт переехал окончательно на JS. Пароли все старые не актуальны. Воспользуйтесь функцией смены пароля. И с этим два момента:

1. Почта отправляется с задержкой до 10 минут.

2. Пока почта не настроена как следует, так что смотрите папку Спам, скорее всего туда улетит.

И еще момент: кое-какие работы еще ведутся, так что возможны перебои. И пока никакие уведомления не работают. Уведомления заработают чуть позже.

И еще важный момент: Если у кого при отправке комментария будет страшно ругаться, почистите localStorage в браузере. Или просто в консоли выполните localStorage.comment_new = null

В ближайшее время выкачу заплатку.

Внимание! Сайт переехал окончательно на JS. Пароли все старые не актуальны. Воспользуйтесь функцией смены пароля. И с этим два момента: 1. Почта отправляется с задержкой до 10 минут. 2. Пока почта не настроена как следует, так что смотрите папку Спам, скорее всего туда улетит. И еще момент: кое-какие работы еще ведутся, так что возможны перебои. И пока никакие уведомления не работают. Уведомления заработают чуть позже. И еще важный момент: Если у кого при отправке комментария будет страшно ругаться, почистите localStorage в браузере. Или просто в консоли выполните localStorage.comment_new = null В ближайшее время выкачу заплатку.

Внимание! Сайт переехал окончательно на JS. Пароли

Да, изменение скорости ответа заметно даже  на глаз.

К тому же не понаслышке знаю технологии, который заложил Николай. Это очень гибко, удобно и надёжно. Объем кода сайта - чуть больше 350кб. При этом никакого php, только чистый js. Это нереально круто.

По себе могу сказать - после работы с реактом, если приходится заниматься php+jquery - охота выкинуть комп в окно. А с реактом я просто отдыхаю.

Да, изменение скорости ответа заметно даже  на глаз. К тому же не понаслышке знаю технологии, который заложил Николай. Это очень гибко, удобно и надёжно. Объем кода сайта - чуть больше 350кб. При этом никакого php, только чистый js. Это нереально круто. По себе могу сказать - после работы с реактом, если приходится заниматься php+jquery - охота выкинуть комп в окно. А с реактом я просто отдыхаю.

Да, изменение скорости ответа заметно даже  на гла

Изменил пароль, письмо пришло практически мгновенно.

Изменил пароль, письмо пришло практически мгновенн

Саша, спасибо на добром слове!

Письмо пришло практически мгновенно - просто повезло. Там очередь рассылки раз в минуту. Ты видимо просто попал в очередной этап.

Саша, спасибо на добром слове! Письмо пришло практически мгновенно - просто повезло. Там очередь рассылки раз в минуту. Ты видимо просто попал в очередной этап.

Саша, спасибо на добром слове! Письмо пришло практ

Не нашел почту обратной связи, так что пишу сюда, на сайте не работает авторизация через логин (через почту всё норм), при создании топика выводится только поле ввода заголовка, при сохранении пишется либо ошибка $data json либо "не заполнен текст", также не знаю фитча это или нет, но в настройках пользователя можно поставить любой пароль, даже пустую строку

Не нашел почту обратной связи, так что пишу сюда,

также сейчас при написании комментария пишется ошибка "топик не найден", но комент добавляется 

также сейчас при написании комментария пишется оши

@alexsoin, сорри за долгий ответ, занят был новым функционалом (чуть позже опубликую и распишу его).

1. Авторизация не может не работать через логин, но работать через емейл, или наоборот. Авторизация проходит в два этапа: сначала поиск пользователя по логину или емейлу, затем уже непосредственно авторизация. При этом на втором этапе не передается ни логин, ни емейл, а только id найденного пользователя. То есть не важно как был найден пользователь, по емейлу или логину, далее процедура идет единая, главное - чтобы пользователь был найден в принципе. У меня есть более прокаченная форма авторизации, которая позволяет выбрать пользователя из нескольких найденных (например, по имени, если человек забыл и логин и емейл (давно не заходил)). Принцип тот же - в итоге отправляется только id выбранного пользователя.

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

2. Создание топиков поправлено.

3. Пароль можно поставить любой, но пустой пароль не сохраняется. То есть пользователь обновляется, но сохранение такого пароля не происходит. Вот код.

4. Про "топик не найден", я так понимаю, это в момент обновления данных страницы. Это очень тонкий момент, который еще предстоит поправить, так как он сразу от нескольких вещей зависит. Если коротко, то на сайте очень активно используется кеширование не уровне провайдера данных, который обеспечивает обмен данными между страницей и сервером (apollo-client). Когда сохраняется коммент (а с ним обновление еще нескольких сущностей), выполняется и подгрузка обновленных данных. Вот в этот момент, если на текущей странице топика, где вы комментарий писали, происходит разрыв между сбросом кеша и подгрузкой данных, получается, что данных топика нет, вот и выходит эта надпись. Момент неприятный, но для работы сайта некритичный. В любом случае, спасибо за фидбэк, я для себя пометил, что надо дополнительно над этим моментом поработать.

@alexsoin, сорри за долгий ответ, занят был новым функционалом (чуть позже опубликую и распишу его). По вашим вопросам: 1. Авторизация не может не работать через логин, но работать через емейл, или наоборот. Авторизация проходит в два этапа: сначала поиск пользователя по логину или емейлу, затем уже непосредственно авторизация. При этом на втором этапе не передается ни логин, ни емейл, а только id найденного пользователя. То есть не важно как был найден пользователь, по емейлу или логину, далее процедура идет единая, главное - чтобы пользователь был найден в принципе. У меня есть более прокаченная форма авторизации, которая позволяет выбрать пользователя из нескольких найденных (например, по имени, если человек забыл и логин и емейл (давно не заходил)). Принцип тот же - в итоге отправляется только id выбранного пользователя. Перепроверьте еще раз, и если не получается, дайте больше деталей с каким логином не получается авторизоваться. 2. Создание топиков поправлено. 3. Пароль можно поставить любой, но пустой пароль не сохраняется. То есть пользователь обновляется, но сохранение такого пароля не происходит. Вот код. 4. Про "топик не найден", я так понимаю, это в момент обновления данных страницы. Это очень тонкий момент, который еще предстоит поправить, так как он сразу от нескольких вещей зависит. Если коротко, то на сайте очень активно используется кеширование не уровне провайдера данных, который обеспечивает обмен данными между страницей и сервером (apollo-client). Когда сохраняется коммент (а с ним обновление еще нескольких сущностей), выполняется и подгрузка обновленных данных. Вот в этот момент, если на текущей странице топика, где вы комментарий писали, происходит разрыв между сбросом кеша и подгрузкой данных, получается, что данных топика нет, вот и выходит эта надпись. Момент неприятный, но для работы сайта некритичный. В любом случае, спасибо за фидбэк, я для себя пометил, что надо дополнительно над этим моментом поработать.

@alexsoin, сорри за долгий ответ, занят был новым

@Fi1osof, авторизоваться через логин у меня не выходит через аккаунт с которого пишу, ввожу логин, система как вы и говорите находит пользователя, затем пишет "введите пароль" ввожу пароль, нажимаю далее, в ответ выходит сообщение об ошибке, о некорректности введенных данных. По такому же принципу ввожу вместо логина почту, и всё срабатывает нормально

@Fi1osof, авторизоваться через логин у меня не вых

Не получается именно с логина alexsoin или какого-то другого?

Не получается именно с логина alexsoin или какого-

да, с него

Странно. Я первым делом попробовал. Хотя конечно же пароль ваш не знаю, поэтому пароль конечно же не вводил. Поменяйте пароль, пришлите мне на n.lanets@modxclub.ru его и инфу с какого браузера пытаетесь (включая версию и ось), я перепроверю. 

Странно. Я первым делом попробовал. Хотя конечно ж

Алекс, у меня получилось с вашими данными зайти в разных браузерах. Чуть позже только еще на винде посмотрю. Но в любом случае, вопросы к форме авторизации теперь и у меня возникли. Я говорил, что в итоге на авторизацию отправляются id пользователя и пароль, а оказалось, что все-таки юзернейм отправляется (видимо заюзал какой-то промежуточный вариант формы :)). На днях буду переделать форму. может решит проблему.

Так же посмотрите, если вдруг вы не на https://, а на http://, попробуйте на https.

Алекс, у меня получилось с вашими данными зайти в разных браузерах. Чуть позже только еще на винде посмотрю. Но в любом случае, вопросы к форме авторизации теперь и у меня возникли. Я говорил, что в итоге на авторизацию отправляются id пользователя и пароль, а оказалось, что все-таки юзернейм отправляется (видимо заюзал какой-то промежуточный вариант формы :)). На днях буду переделать форму. может решит проблему. Так же посмотрите, если вдруг вы не на https://, а на http://, попробуйте на https.

Алекс, у меня получилось с вашими данными зайти в

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

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

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

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

Это всё сила React

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действительно очень нужный инструмент. Позволяет навести порядок в запросах к серверу

Действительно очень нужный инструмент. Позволяет н

мне понравилось, поюзал :D правда практического применения пока не было, но уже преставляю где можно использовать

мне понравилось, поюзал :D правда практического пр

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

Когда по отдельности берешь эти данные, тогда еще ничего. А когда надо, к примеру, такое получить:

   По каждому пользователю список его работ

       В каждой работе получить список участников работы

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

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

                Сколько компаний работает по данному направлению

Уровней вложенности может быть очень много. И каждому может понадобиться свой набор данных. Попробуй-ка на классических технологиях такое реализовать (конструктор запросов). 

На простых сайтах, конечно, это решение скорее всего будет избыточным. Но на сайтах покрупнее очень даже нужная штука. Вот смотри структура данных здесь (далеко не полная): Пользователь Команда Работа портфолио Вид деятельности Топик Комментарий Когда по отдельности берешь эти данные, тогда еще ничего. А когда надо, к примеру, такое получить: Список пользователей По каждому пользователю список его работ В каждой работе получить список участников работы По каждому участнику получить список направлений, по которым он участвовал в проекте По каждому направлению получить сколько всего работ по данному направлению есть Сколько компаний работает по данному направлению и т.д. и т.п. Уровней вложенности может быть очень много. И каждому может понадобиться свой набор данных. Попробуй-ка на классических технологиях такое реализовать (конструктор запросов).

На простых сайтах, конечно, это решение скорее все

Николай, большое спасибо за уроки! Намереваюсь попробовать Vulcan.js

Николай, большое спасибо за уроки! Намереваюсь поп

ОК. Как будут результаты, если что, напишите небольшой топик что и как там работает, плиз. 

А я свой один проект переделываю, полностью на JS. Очень интересные техники новые освоил, и в GraphQL продвинулся. Скоро новые уроки появятся.

ОК. Как будут результаты, если что, напишите небольшой топик что и как там работает, плиз. А я свой один проект переделываю, полностью на JS. Очень интересные техники новые освоил, и в GraphQL продвинулся. Скоро новые уроки появятся.

ОК. Как будут результаты, если что, напишите небол

Николай, вижу мой совет про graphql в первом уроке был принят ))). Благодарю за этот урок, Вы занимаетесь хорошим делом! Хотел бы добавить в преимущества:

1. Структура ответа всегда точно повторяет структуру запроса, все сталкивались с проблемой когда в ресте поменялась структура объекта  в ответе и все ломалось. И версионность больше не нужна по этой причине.

2. Возможность работать сразу с несколькими источниками данных. Поскольку по сути graphql это агрегатор, мы можем накрутить работу сразу с несколькими базами и соединять данные в одну выборку.

3. Быстро разворачивается в сравнении с рест. Если написать генератор для моделей, вообще за 5 минут. И за счёт того, что всего 1 эндпоинт мы получаем полнофункциональный вариант по сути, только связи руками накрутить. Ну исключение с мутациями, на них генератор не сделать.

Николай, вижу мой совет про graphql в первом уроке был принят ))). Благодарю за этот урок, Вы занимаетесь хорошим делом! Хотел бы добавить в преимущества: 1. Структура ответа всегда точно повторяет структуру запроса, все сталкивались с проблемой когда в ресте поменялась структура объекта  в ответе и все ломалось. И версионность больше не нужна по этой причине. 2. Возможность работать сразу с несколькими источниками данных. Поскольку по сути graphql это агрегатор, мы можем накрутить работу сразу с несколькими базами и соединять данные в одну выборку. 3. Быстро разворачивается в сравнении с рест. Если написать генератор для моделей, вообще за 5 минут. И за счёт того, что всего 1 эндпоинт мы получаем полнофункциональный вариант по сути, только связи руками накрутить. Ну исключение с мутациями, на них генератор не сделать.

Николай, вижу мой совет про graphql в первом уроке

Да, Артем, сейчас граф - один из моих основных инструментов и ввел я его уже на нескольких проектах. Очень круто он себя показывает при внедрении на уже готовые проекты. К примеру, не так давно я анонсировал запуск проекта http://troika-gorod.ru/ , который написан полностью на JS, а MODX используется только для проброса и модификации API-запросов. И вот они обратились за доработками, и я решил, что раз функционал растет, то имеет смысл граф ввести, чтобы потом не было мучительно больно. Отмечу, что ввести граф, на самом деле - это совсем не 5 минут (если сайт - не сайт-визитка), во всяком случае у меня. Я руками все пишу. По моим наблюдениям, на среднем проекте только листинг основных запросов составляет строк 500, и это еще при условии использования фрагментов, которые вставлять можно в разные части. На тройке - это 1000 строк. Все это - три десятка АПИ-запросов. http://joxi.ru/bmoY6bGSMdRzpA 

Так вот, здесь себя граф показывает не только как отличное средство для построения запроса, но и как архитектор АПИ. Вот пара примеров с этой тройкой: 

Справа - это предоставленная документация. Видно, что вкралась опечатка.

А вот пример, почему такое невозможно с графом: 

А вот наглядный пример, для чего это делается: вот я одним запросом получаю сразу три блока информации http://joxi.ru/bmoY6bGSMdRJpA 

При чем в своем конечном ответе я получаю именно один конечный многоуровневый JSON. А то, что граф выполнил для сбора этой информации три запроса - так это как раз и демонстрирует то, о чем говорит Артем - возможность работать сразу с несколькими источниками данных. Здесь три запроса выполняется только потому, что на стороне сервера не работает граф и он просто не может вернуть данные одним ответом. А вот на другом моем проекте (и не только на нем), граф крутится и на сервере и в ответе в одном я получаю все нужные мне данные 

Кстати, в связке с сервером, у меня получилась вообще очень интересная связка: у меня и на сервере, и на клиенте используется единая схема. Это позволяет, во-первых, на сервер в запросе слать не портянку, а просто название операции с параметрами. К примеру, на получение этих данных отправляется вот такой запрос:

А во-вторых, я эту же модель, просто с другими обработчиками, использую и на стороне клиента. То есть когда у меня данные подгружены в браузер в хранилища, я могу выполнять структурированные запросы прям в браузере. К примеру, вот так я получаю в браузере данные для карты, со всеми нужными вложенностями, и совершенно без обращения к серверу

Короче, про него можно очень много всего рассказывать. И надо отметить, что работа с ним - это не всегда праздник. В том же браузере, из-за того, что он использует промисы, он не рассчитан на множественный вызов (то есть когда во внутренних резолверах выполняешь еще запросы на граф). В случае сотен вызовов в рамках одного запроса, выборка конечная может составить 10 секунд и более :) Но если правильно оптимизировать все, то этот же объем данных будет получен менее чем за секунду.

Да, Артем, сейчас граф - один из моих основных инструментов и ввел я его уже на нескольких проектах. Очень круто он себя показывает при внедрении на уже готовые проекты. К примеру, не так давно я анонсировал запуск проекта http://troika-gorod.ru/ , который написан полностью на JS, а MODX используется только для проброса и модификации API-запросов. И вот они обратились за доработками, и я решил, что раз функционал растет, то имеет смысл граф ввести, чтобы потом не было мучительно больно. Отмечу, что ввести граф, на самом деле - это совсем не 5 минут (если сайт - не сайт-визитка), во всяком случае у меня. Я руками все пишу. По моим наблюдениям, на среднем проекте только листинг основных запросов составляет строк 500, и это еще при условии использования фрагментов, которые вставлять можно в разные части. На тройке - это 1000 строк. Все это - три десятка АПИ-запросов. http://joxi.ru/bmoY6bGSMdRzpA Так вот, здесь себя граф показывает не только как отличное средство для построения запроса, но и как архитектор АПИ. Вот пара примеров с этой тройкой: Справа - это предоставленная документация. Видно, что вкралась опечатка. А вот еще: А вот пример, почему такое невозможно с графом: А вот наглядный пример, для чего это делается: вот я одним запросом получаю сразу три блока информации http://joxi.ru/bmoY6bGSMdRJpA При чем в своем конечном ответе я получаю именно один конечный многоуровневый JSON. А то, что граф выполнил для сбора этой информации три запроса - так это как раз и демонстрирует то, о чем говорит Артем - возможность работать сразу с несколькими источниками данных. Здесь три запроса выполняется только потому, что на стороне сервера не работает граф и он просто не может вернуть данные одним ответом. А вот на другом моем проекте (и не только на нем), граф крутится и на сервере и в ответе в одном я получаю все нужные мне данные Кстати, в связке с сервером, у меня получилась вообще очень интересная связка: у меня и на сервере, и на клиенте используется единая схема. Это позволяет, во-первых, на сервер в запросе слать не портянку, а просто название операции с параметрами. К примеру, на получение этих данных отправляется вот такой запрос: А во-вторых, я эту же модель, просто с другими обработчиками, использую и на стороне клиента. То есть когда у меня данные подгружены в браузер в хранилища, я могу выполнять структурированные запросы прям в браузере. К примеру, вот так я получаю в браузере данные для карты, со всеми нужными вложенностями, и совершенно без обращения к серверу Короче, про него можно очень много всего рассказывать. И надо отметить, что работа с ним - это не всегда праздник. В том же браузере, из-за того, что он использует промисы, он не рассчитан на множественный вызов (то есть когда во внутренних резолверах выполняешь еще запросы на граф). В случае сотен вызовов в рамках одного запроса, выборка конечная может составить 10 секунд и более :) Но если правильно оптимизировать все, то этот же объем данных будет получен менее чем за секунду.

Да, Артем, сейчас граф - один из моих основных инс

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

С ошибками Вы точно подметили, один из значимых плюсов!. Стоит тоже в статью добавить )). Примеры отличные !)

Николай, да тут смысл в том, чтобы одним запросом к серверу получать сразу все данные. Кстати этот момент хорошо работает и в случае с серверным рендерингом. Мы любые данные можем получить одним запросом и не нужно ничего комбинировать или слать несколько. Поскольку серверный рендеринг работает синхронно это огромное преимущество. Во первых мы не перегружаем локальный сокет петлями, во вторых один запрос (который распараллелить внутри GraphQL) выполняется значительно быстрей, что напримую влияет на первую выдачу HTML в браузер С ошибками Вы точно подметили, один из значимых плюсов!. Стоит тоже в статью добавить )). Примеры отличные !)

Николай, да тут смысл в том, чтобы одним запросом 

Предлагаю следующий урок посвятить серверному рендерингу :) 

Предлагаю следующий урок посвятить серверному ренд

Круто. У нас вот из-за проблемы получения на старте всего стейта приложения в итоге отказались от сервер сайд рендеринга. Или он просто не работал. Я в детали сильно не углублялся - у меня было полно других задачь. Но тимлид в итоге назвал ошибкой выбор reflux вместо redux. Redux как раз эту проблему сервер сайд рендеринга бы решил. 

Круто. У нас вот из-за проблемы получения на старт

На самом деле не думаю, что reflux, redux или flux решили бы эту проблему. Да, на них можно отправить изменения, которые повлияли бы на запрос данных и в итоге получили бы измененный стейт приложения, но повторюсь, новые компоненты могут порождать другие компоненты и т.п. Это бы добавило коллизий. Этих коллизий можно было бы избежать только в случае, когда все изменения проходят через подобные хранилища без самостоятельной логики в самих компонентах. То есть компоненты только для отрисовки. Но на своем опыте я осознал, что подобные решения слишком неповоротливые получаются. Да, предсказуемость растет, но гибкость падает и объем кода растет. Я для себя решил это так: при заходе на страницу (первый запрос на сервер), система через react-router получает запрашиваемый компонент (тот, который на основе настроек роутера отрабатывался бы на стороне браузера, на основании адресной строки). У этого компонента запрашивается метод получения данных. Это GraphQL-запрос. Именно GraphQL в данном случае спасает, потому что через него можно одним запросом получить сразу несколько дата-сущностей с различной вложенностью. Полученный результат возвращается в обработчик запроса, который тогда только вызывает непосредственно реакт-компонент через react-dom-server с непосредственной отрисовкой HTML. Тут он уже получает не только HTML, но и конечный снимок глобального стейта (то есть в этот момент в самом рекат-компоненте может выполниться дополнительная логика на основании переданного стейта, которая не требует ожидания асинхронных запросов и ре-рендеринга). Этот уже HTML передается вместе со снимком стейта в брайзер и в этот момент, даже после выполнения реакт-компонента на стороне браузера, мы получаем точную копию того, что произошло на сервере. А далее уже в браузере работает полноценное веб-приложение со всеми асинхронными запросами, отсутствием перезагрузки страницы и т.п. Попробуйте отключить JS и зайти на сайт бань, 95% сайта будет работать без JS, вы почти не заметите разницы, все ссылки рабочие, и даже если вы будете авторизованы, с сервера будет приходить код с вашей аватаркой, учетом уровней доступов и т.п.

На самом деле не думаю, что reflux, redux или flux

Николай приветствую! Очень обрадовала твоя статья! В целом динамика твоих изысканий все круче и все выше! Познавательно и реально интересно! Такой вот вопрос, я взялся изучать Angular 4, как ты смотришь на возможности этого фреймворка, в том числе в свете твоих работ? Может смысл есть его функционал задействовать?

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

С ангулар в бою так и не столкнулся, и нет особого желания. Это готовый фреймворк, а мне больше нравится низкоуровневость. К тому же помимо реакта, фейсбук предлагает целый спектр попутных технологий: react, draft-js, graphql, flux, immutable, react-native, а теперь еще и react-vr. Это очень широкий и объемный спектр технологий. На мой взгляд это направление перспективно, не вижу сейчас смысла дергаться еще куда-то. 

Сергей, добрый день. С ангулар в бою так и не столкнулся, и нет особого желания. Это готовый фреймворк, а мне больше нравится низкоуровневость. К тому же помимо реакта, фейсбук предлагает целый спектр попутных технологий: react, draft-js, graphql, flux, immutable, react-native, а теперь еще и react-vr. Это очень широкий и объемный спектр технологий. На мой взгляд это направление перспективно, не вижу сейчас смысла дергаться еще куда-то.

Сергей, добрый день. С ангулар в бою так и не стол

Обана... Не уж то существует в интернете место, где есть что-то интересное на счет совместной работы nodeJS и MODX... У меня сейчас мало времени, чтобы успеть нормально пробежаться по всем статьям, по поводу них, но 100% уже завтра вечером сяду и все прочитаю.  Сам сейчас просто в неописуемом восторге от JavaScript. Все началось с ознакомления с Google'овским Progressive WebApp (https://developers.google.com/web/progressive-web-apps/ ), а в частности ServiceWorker и его возможностями для работы сайтов из оффлайна + бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта... И с тех пор пошло-поехало... Но все это время меня удивляла одна простая вещь: если взять тот же самый Gulp, то на самом деле сборка шаблонов на нем не такая уж и сложная задача... Но при этом на том же modx.pro ни слова на эту тему... А тут на тебе, аж целый React :-) Если где-то еще будет информация про Polyfill, то жизнь уж совсем станет сказкой :-) 

P.S. ReactVR - это реализация виртуальной реальности...  И это не просто "очень широкий и объемный спектр технологий" , но так же и ОЧЕНЬ не слабых знаний геометрии, как всей остальной математики.

Обана... Не уж то существует в интернете место, где есть что-то интересное на счет совместной работы nodeJS и MODX... У меня сейчас мало времени, чтобы успеть нормально пробежаться по всем статьям, по поводу них, но 100% уже завтра вечером сяду и все прочитаю.  Сам сейчас просто в неописуемом восторге от JavaScript. Все началось с ознакомления с Google'овским Progressive WebApp (https://developers.google.com/web/progressive-web-apps/ ), а в частности ServiceWorker и его возможностями для работы сайтов из оффлайна + бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта... И с тех пор пошло-поехало... Но все это время меня удивляла одна простая вещь: если взять тот же самый Gulp, то на самом деле сборка шаблонов на нем не такая уж и сложная задача... Но при этом на том же modx.pro ни слова на эту тему... А тут на тебе, аж целый React :-) Если где-то еще будет информация про Polyfill, то жизнь уж совсем станет сказкой :-) P.S. ReactVR - это реализация виртуальной реальности...  И это не просто "очень широкий и объемный спектр технологий" , но так же и ОЧЕНЬ не слабых знаний геометрии, как всей остальной математики.

Обана... Не уж то существует в интернете место, гд

Реакта здесь будет много. Я сейчас заканчиваю перенос довольно крупного тематического портала на свой движок (готовых комплексных решений под себя так и не нашел, поэтому пилю свое сам. С учетом того, что на базе того, на чем работают городские бани, у меня еще один крупные проект создается, и за эти выходные, за два дня, я почти полностью переписал 10-ти летный проект, который крутился на самописке, на эту новую платформу, думаю, могу уже называть это движком). В начале года будет очередное масштабное обновление сайта Клуба на этот движок, так что все это будет неотъемлемой частью MODX-Клуба, и будет довольно подробно освещаться.

Я не рассматриваю MODX и Javascript как конкурирующие взаимозаменяемые технологии. Они вполне могут существовать совместно. MODX более проще и более предсказуемый, и вполне годится для бэкэнда. А Javascript можно использовать для обновления проекта, создания более современного фронта. Собственно, так же как ангулар и все остальное используется в связке с ларавелем. Далеко же не все, кто использует их в связке, говорит "Так, от ларки отказываемся, теперь только кашерный javascript!".

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

VR всерьез заинтересовался после вот это статьи: 

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

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

>> бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта...

Бани - довольно тяжеловесный проект получился. Там полно мест еще, где надо оптимизировать. Но даже при этом гугл-спид показывает для компьютеров 97/100 

Для мобильников результат похуже, но тоже не плохой, 75-85.

Реакта здесь будет много. Я сейчас заканчиваю перенос довольно крупного тематического портала на свой движок (готовых комплексных решений под себя так и не нашел, поэтому пилю свое сам. С учетом того, что на базе того, на чем работают городские бани, у меня еще один крупные проект создается, и за эти выходные, за два дня, я почти полностью переписал 10-ти летный проект, который крутился на самописке, на эту новую платформу, думаю, могу уже называть это движком). В начале года будет очередное масштабное обновление сайта Клуба на этот движок, так что все это будет неотъемлемой частью MODX-Клуба, и будет довольно подробно освещаться. Я не рассматриваю MODX и Javascript как конкурирующие взаимозаменяемые технологии. Они вполне могут существовать совместно. MODX более проще и более предсказуемый, и вполне годится для бэкэнда. А Javascript можно использовать для обновления проекта, создания более современного фронта. Собственно, так же как ангулар и все остальное используется в связке с ларавелем. Далеко же не все, кто использует их в связке, говорит "Так, от ларки отказываемся, теперь только кашерный javascript!". Про полифил читал, но пока не вижу для себя необходимости его использовать. Мне достаточно того, что реакт позволяет очень быстро менять свойства выводимого компонента, и нагромождать технологии - это скорее всего лишнее будет. VR всерьез заинтересовался после вот это статьи: Немного поигрался как пользователь, показалось очень занятным направлением. Математики и геометрики за нас уже все сделали. К слову, после того. как это чуть изучил, открыл для себя, что в ютубе очень много 3D-контента. В тот момент немного приуныл, ощутил, как будущее проходит мимо меня. То есть сидишь, делаешь такой что знаешь, а тут уже вокруг много того появляется, чего ты просто не заметил. P.S. >> бешеная скорость загрузки/работы за счет асинхронности у всех элементов сайта... Бани - довольно тяжеловесный проект получился. Там полно мест еще, где надо оптимизировать. Но даже при этом гугл-спид показывает для компьютеров 97/100 Для мобильников результат похуже, но тоже не плохой, 75-85.

Реакта здесь будет много. Я сейчас заканчиваю пере

По поводу рейтинга бань могу дать пару советов:

1) Gulp - для сборки фронта - это наше все. Глянь модули gulp-critical-css (Крит. CSS думаю знаешь, что такое) + gulp-uncss ( анализирует HTML код и находит все неиспользуемые и продублированные стили).

2) На счет кэша браузера, если не путаю, то вроде как, если в редакторе счетчика метрика на Яндексе выбрать "Альтернативный CDN", то проблема уходит.

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

P.S. Когда узнал про gulp-uncss и то, что он "анализирует HTML код и находит все неиспользуемые и продублированные стили и удаляет их", то ,в отличии от тебя, не просто " В тот момент немного приуныл"... Я конкретно о&$%ел. Я несколько лет назад понял, что наступает новая глава в истории программирования, когда сидел за очень слабым офисным компьютером и играл в Quake 3 прямо в браузере...  Ну а далее зайдя в Google Experiments я окончательно сформулировал для себя, что пришла эра JavaScript... 

UPD: Глянул сайт и еще добавлю gulp-autoprefixer... т.к. нет "-webkit-" , "-moz-" и т.п. для поддержки старых браузеров... Работал как-то раньше с банькой одной и могу сказать со 100% уверенностью: публика там и на 8 Internet Explorer может сидеть :-)))))

По поводу рейтинга бань могу дать пару советов: 1) Gulp - для сборки фронта - это наше все. Глянь модули gulp-critical-css (Крит. CSS думаю знаешь, что такое) + gulp-uncss ( анализирует HTML код и находит все неиспользуемые и продублированные стили). 2) На счет кэша браузера, если не путаю, то вроде как, если в редакторе счетчика метрика на Яндексе выбрать "Альтернативный CDN", то проблема уходит. 3) На счет картинок не думаю, что смогу что-то новое для тебя сказать... Мне почему-то кажется, что скорее всего ты тут банально схалтурил :-) P.S. Когда узнал про gulp-uncss и то, что он "анализирует HTML код и находит все неиспользуемые и продублированные стили и удаляет их", то ,в отличии от тебя, не просто " В тот момент немного приуныл"... Я конкретно о&$%ел. Я несколько лет назад понял, что наступает новая глава в истории программирования, когда сидел за очень слабым офисным компьютером и играл в Quake 3 прямо в браузере...  Ну а далее зайдя в Google Experiments я окончательно сформулировал для себя, что пришла эра JavaScript... UPD: Глянул сайт и еще добавлю gulp-autoprefixer... т.к. нет "-webkit-" , "-moz-" и т.п. для поддержки старых браузеров... Работал как-то раньше с банькой одной и могу сказать со 100% уверенностью: публика там и на 8 Internet Explorer может сидеть :-)))))

По поводу рейтинга бань могу дать пару советов: 1)

Картинок там только две, на которых он ругается - аватарки 150 на 150, там, где они реально меньше нужны. На счет "схалтурил", ты вообще погорячился. С картинками как раз у меня там все вполне нормально. В модели прописаны сразу несколько вариаций картинок.

Для топиков еще больше вариаций.

Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. Но я не планирую в угоду этого архитектуру менять. С мобильника я пробовал, уже через 2 секунды я могу взаимодействовать со страницей, до того, как 15% контента подгрузилось (имеется ввиду со скриптами и т.п.), я считаю, что это вполне нормально. Я без 100/100 вполне переживу :)

С советами этими чуть опоздал. 

1. Галп, ИМХО - прошлый век. От него аж корежит. Отладка в нем - вообще Адовый АДъ. Пока webpack. Позже может на фейсбуковый сборщик пересяду, если станет стандартом.

2. Стили - вообще не актуально. Глянь CSS. Там fontawesome и бутстрап. От одного и второго откажусь скоро, они просто прилетели наследием, просто потому что мне было лень переделывать шапку. А основные стили в теле документа ищи. Ты их не зачистишь сторонними решениями, там все уникальное. Фишка в том, что это динамические стили. Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta

      "image": "assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
      "imageFormats": {
        "thumb": "images/resized/thumb/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
        "small": "images/resized/small/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
        "middle": "images/resized/middle/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg",
        "big": "images/resized/big/assets/images/lazy/3db3624b49a80589c6704af6759ecdff.jpeg"
      },

Картинок там только две, на которых он ругается - аватарки 150 на 150, там, где они реально меньше нужны. На счет "схалтурил", ты вообще погорячился. С картинками как раз у меня там все вполне нормально. В модели прописаны сразу несколько вариаций картинок. Для топиков еще больше вариаций. Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. Но я не планирую в угоду этого архитектуру менять. С мобильника я пробовал, уже через 2 секунды я могу взаимодействовать со страницей, до того, как 15% контента подгрузилось (имеется ввиду со скриптами и т.п.), я считаю, что это вполне нормально. Я без 100/100 вполне переживу :) С советами этими чуть опоздал. 1. Галп, ИМХО - прошлый век. От него аж корежит. Отладка в нем - вообще Адовый АДъ. Пока webpack. Позже может на фейсбуковый сборщик пересяду, если станет стандартом. 2. Стили - вообще не актуально. Глянь CSS. Там fontawesome и бутстрап. От одного и второго откажусь скоро, они просто прилетели наследием, просто потому что мне было лень переделывать шапку. А основные стили в теле документа ищи. Ты их не зачистишь сторонними решениями, там все уникальное. Фишка в том, что это динамические стили. Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta

Картинок там только две, на которых он ругается - 

 >>>  На счет "схалтурил", ты вообще погорячился

Это была шутка :-) Я прекрасно понимаю, что было что-то из серии:

>>>  аватарки 150 на 150, там, где они реально меньше нужны. 

>> Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. 

Это-то понятно... В будущем Google видит Progressive WebApp, а у них как раз по ним и приколы главные. Вот, к примеру результаты прогона сайта бань в LightHouse:

Но тут уже из другой оперы, конечно, тестирование. Особенно меня радует кэширование на стороне клиента и за счет этого работа даже без интернета:

https://developers.google.com/web/tools/lighthouse/audits/http-200-when-offline 

Если мало-ли вдруг понадобится, то вот чеклист:
https://developers.google.com/web/progressive-web-apps/checklist 

>>>  На счет "схалтурил", ты вообще погорячился Это была шутка :-) Я прекрасно понимаю, что было что-то из серии: >>>  аватарки 150 на 150, там, где они реально меньше нужны. >> Основное, на что ругается гугл, так это на объем HTML-кода "Для показа верхней части страницы понадобилось 156,8 КБ данных с сервера" и долгий ответ сервера - +-1 секунда. Это-то понятно... В будущем Google видит Progressive WebApp, а у них как раз по ним и приколы главные. Вот, к примеру результаты прогона сайта бань в LightHouse: https://yadi.sk/i/ohsPgjQQ3QHJXd Но тут уже из другой оперы, конечно, тестирование. Особенно меня радует кэширование на стороне клиента и за счет этого работа даже без интернета: https://developers.google.com/web/tools/lighthouse/audits/http-200-when-offline Если мало-ли вдруг понадобится, то вот чеклист:
https://developers.google.com/web/progressive-web-apps/checklist

>>>  На счет "схалтурил", ты вообще погорячился Эт

>>> Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta 

Про jscss нет, не слышал... Я особо в React не лазал...  Пока что в сторону Polymer буду курс держать... Там уж точно:

>>> Раз ... в документе есть, значит есть какой-то элемент, для которого это ... нужно

Да и на счет... >>> Раз правило в документе есть, значит есть какой-то элемент, для которого это правило нужно. jscss слышал? material-ui@alpha/beta Про jscss нет, не слышал... Я особо в React не лазал...  Пока что в сторону Polymer буду курс держать... Там уж точно: >>> Раз ... в документе есть, значит есть какой-то элемент, для которого это ... нужно :-)

Да и на счет... >>> Раз правило в документе есть, 

ОК, возьму на заметку, но сейчас для меня это пока рановато. Я развиваю самую логику, и только когда она будет окончена, можно будет заниматься оптимизацией. Сейчас в таком случае это будет Разработка-Оптимизация-Тестирование-Разработка и так далее в цикле. Лишнее звено, при чем весьма ресурсоемкое. 

ОК, возьму на заметку, но сейчас для меня это пока

Вот еще один проект запустил на этом движке: http://pivkarta.ru/ 

Этот проект уже гораздо сложнее и объемней, чем городские бани. Яндекс в результаты выдает 83 000 страниц. 

- 555 + 175 записей в блоги и событий.

- 26 500 пользователей (не вычищал фейков, пока не знаю долю реальных пользователей, но их большая часть).

В общем, сайт предъявил серьезные требования к разработке и оптимизации. Когда запустил первичную версию, нода на запуске съедала больше 2 Гб оперативки (затем в стабильном режиме 700+ метров), получение всех API-данных занимало более 40 сек, и страницу отдавало за 1-10 сек. 

Сейчас штатный режим менее 500 метров требует (на запуске пик чуть более гига), страницу отдает 0.4-1 сек (на паре страниц до 1,5 сек, но это поправлю).

Вот еще один проект запустил на этом движке: http://pivkarta.ru/ Этот проект уже гораздо сложнее и объемней, чем городские бани. Яндекс в результаты выдает 83 000 страниц. Сущностей на сайте: - 1 500 видов пива. - 555 + 175 записей в блоги и событий. - 3 300+ комментариев. - 3 500+ заведений. - 8 300+ фотографий. - 26 500 пользователей (не вычищал фейков, пока не знаю долю реальных пользователей, но их большая часть). В общем, сайт предъявил серьезные требования к разработке и оптимизации. Когда запустил первичную версию, нода на запуске съедала больше 2 Гб оперативки (затем в стабильном режиме 700+ метров), получение всех API-данных занимало более 40 сек, и страницу отдавало за 1-10 сек. Сейчас штатный режим менее 500 метров требует (на запуске пик чуть более гига), страницу отдает 0.4-1 сек (на паре страниц до 1,5 сек, но это поправлю).

Вот еще один проект запустил на этом движке: http:

Прямо в тему оповещение пришло про комментарий. Сейчас изучаю сайт один, который после 2-3 месяцев разработки ... Мне вот интересно , а степень моего веселья понять можно всего лишь по скрину файлового менеджера из админки сайта? 34к взял чел за натяжку на MODX. 

P.S. почему-то правда картинка через место одно выводится в теле комментария, поэтому надо смотреть по ссылке.

P.P.S. !!!! 2-3 МЕСЯЦЕВ НЕ МОЕЙ РАЗРАБОТКИ  !!!!! 

Прямо в тему оповещение пришло про комментарий. Сейчас изучаю сайт один, который после 2-3 месяцев разработки ... Мне вот интересно , а степень моего веселья понять можно всего лишь по скрину файлового менеджера из админки сайта? 34к взял чел за натяжку на MODX. P.S. почему-то правда картинка через место одно выводится в теле комментария, поэтому надо смотреть по ссылке. P.P.S. !!!! 2-3 МЕСЯЦЕВ НЕ МОЕЙ РАЗРАБОТКИ  !!!!! https://yadi.sk/i/jKGUTsCK3QKcKm

Прямо в тему оповещение пришло про комментарий. Се

Чтот я не уловил посыла. Можно чуть разжевать?

Посыл в том, что хочу узнать твое мнение, т.к. не могу понять: JS кретинизм- это проблема только среди MODX разрабов или сейчас вообще везде острая нехватка Frontend разрабов? В последнее время все больше поражает, какие все крутые/важные на modx.pro , хотя кроме пыхи и AjaxForm/AjaxSnippet от Васи не знают ничего. Трындец какой-то. 

Посыл в том, что хочу узнать твое мнение, т.к. не 

Я все равно не уловил в чем JS-кретинизм. Ты про то, что кто-то накидал все в корень сайта? Ну да, это фигня полная. Но это не только касаемо JS косяк. Кидать в корень что угодно - глупость.