На самом деле не думаю, что reflux, redux или flux решили бы эту проблему. Да, на них можно отправить изменения, которые повлияли бы на запрос данных и в итоге получили бы измененный стейт приложения, но повторюсь, новые компоненты могут порождать другие компоненты и т.п. Это бы добавило коллизий. Этих коллизий можно было бы избежать только в случае, когда все изменения проходят через подобные хранилища без самостоятельной логики в самих компонентах. То есть компоненты только для отрисовки. Но на своем опыте я осознал, что подобные решения слишком неповоротливые получаются. Да, предсказуемость растет, но гибкость падает и объем кода растет. Я для себя решил это так: при заходе на страницу (первый запрос на сервер), система через react-router получает запрашиваемый компонент (тот, который на основе настроек роутера отрабатывался бы на стороне браузера, на основании адресной строки). У этого компонента запрашивается метод получения данных. Это GraphQL-запрос. Именно GraphQL в данном случае спасает, потому что через него можно одним запросом получить сразу несколько дата-сущностей с различной вложенностью. Полученный результат возвращается в обработчик запроса, который тогда только вызывает непосредственно реакт-компонент через react-dom-server с непосредственной отрисовкой HTML. Тут он уже получает не только HTML, но и конечный снимок глобального стейта (то есть в этот момент в самом рекат-компоненте может выполниться дополнительная логика на основании переданного стейта, которая не требует ожидания асинхронных запросов и ре-рендеринга). Этот уже HTML передается вместе со снимком стейта в брайзер и в этот момент, даже после выполнения реакт-компонента на стороне браузера, мы получаем точную копию того, что произошло на сервере. А далее уже в браузере работает полноценное веб-приложение со всеми асинхронными запросами, отсутствием перезагрузки страницы и т.п. Попробуйте отключить JS и зайти на сайт бань, 95% сайта будет работать без JS, вы почти не заметите разницы, все ссылки рабочие, и даже если вы будете авторизованы, с сервера будет приходить код с вашей аватаркой, учетом уровней доступов и т.п.
Круто. У нас вот из-за проблемы получения на старте всего стейта приложения в итоге отказались от сервер сайд рендеринга. Или он просто не работал. Я в детали сильно не углублялся - у меня было полно других задачь. Но тимлид в итоге назвал ошибкой выбор reflux вместо redux. Redux как раз эту проблему сервер сайд рендеринга бы решил.
Понял, спасибо! Тогда буду потихоньку все переписывать. Надеялся на временное решение в виде какого-нибудь memcached
Никакой настройки (связка nginx+php-fmp без какого-либо тюнинга). Оптимизация самого сайта. Про это я много статей писал.
0,07 – это шикарный результат. А можете вкратце поделиться рецептом настройки PHP именно в серверной части?
А это не моя статья. Сам я на php-7.1 получаю 0.07 сек и это меня вполне устраивает.
Да, супер! Спасибо за быстрый ответ. Жаль, что время PHP5 давно ушло :( Может быть у вас есть что-нибудь на примете более актуальное, для 7 версии ?
Сломалась ссылка на конфигурирование и проверку PHP http://modxclub.ru/blog/sandbox/175.html :( Как бы её найти теперь?
Нет, этот метод используется уже непосредственно для обновления категорий, то есть когда временные данные уже записаны во временную таблицу и взяты для обновления категорий на сайте. Вам нужен метод StepWriteTmpCategories, то есть тот, в котором готовятся данные для записи во временную таблицу. Какой вы ключ будете использовать для задания уникальности - это уже ваше дело. Вы сами что для себя логически там используете? Названия категорий? Если да, и если они уникальные, то да, можете их и использовать. Только имейте ввиду, что поле ключа ограничено по длине (смотрите системные настройки в modImporter, а лучше прям в базе данных смотрите структуру таблицы modx_site_content). Если так, то можете брать md5() заголовка. Тогда длина ключа будет фиксированное, а значение уникальное. Но в таком случае, если у вас заголовок в данных импорта хоть на символ изменится, будет создана новая категория.