Возможно ли совмещение серверного рендера на PHP и современных JS фреймворков.

[Yoskaldyr]

Тут понадобилось немного проапгрейдить клиентскую часть старого легаси.
Хочется добавить стейт для клиентского приложения, какую никакую реактивность (лайв биндинги и т.д.), вся навигация после инициализации посредством ajax запросов + js, без потери стейта. Т.к. хочется переписывать эволюционно, а не революционно, то желательно чтобы весь основной контент рендерился на серверной стороне, а всякие вспомогательные ui-компоненты на стороне js.

Из готовых решений смотрел Inertia.js and Livewire.
В первом случае (Inertia.js) не нравится что все заточено именно под js рендер, хотя работа со стейтом и переходами удобна в плане взаимодействия с серверным пхп.
Во втором (Livewire) не нравится что вообще все рендерится и вообще вся логика на стороне пхп на любое изменение компонента - ajax запрос (в некоторых случаях это может привести к ооочень плачевным последствиям). Т.е. компонентный подход в несколькими уровнями вложенности отпадает

Думал насчет собственного велосипеда на подобии https://github.com/lootmarket/laravel-vue-blade-component. Но вот не знаю стоит ли... Может есть еще какие альтернативы? Или это реально извращение и даже таких мыслей не должно появляться?

P.S. Вопрос не стоит как делать обычное SPA или SPA + SSR на ноде, а именно гибридный вариант рендера на пхп.

 

[Adelf]

Или это реально извращение и даже таких мыслей не должно появляться?

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

 

[Yoskaldyr]

Просто как быть с тем что уже есть? выкинуть и написать с нуля - не вариант

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

 

[grigori]

@Yoskaldyr мои мысли такие:
1. Переписать то, что работает, обычно нельзя. Причин много, офтопик будет. Новое потребует год его дорабатывать еще, после написания.
2. Обновить front-end - это не просто дизайн сменить. Это редизайн, новый UX и flow для мобильных телефонов. Когда сайт писали, мобильных не было, а сейчас там 80% траффика.
Вывод - прапгрейдить немного обычно нельзя. Апгрейдить надо много.
Надо разделить логику и клиента. Сервер с логикой можно оставить на PHP, а клиентскую часть надо переводить на API - RESTful или GraphQL.
"лайв биндинги" подразумевают API.
Плавный переход маловероятен. Клиента скорее всего надо писать на react/vie, а это самостоятельные приложения и смешивать их не получится. Можно частями переделывать. Все зависит от бюджета проекта.

 

[Yoskaldyr]

В том то и дело что обновлять/заменять фронтенд не надо (диз и ui и так нормальный и mobilefirst).
Проблема в расширении и затратах на допиливание нового функционала. Все можно сделать тупо на jquery, только вот времени на это тратится в разы больше и код получается совсем не поддерживаемый... И даже в этом случае затраты значительно меньше, чем затраты на переписывание полностью на классический SPA

К тому же у SPA много недостатков, даже вместе с SSR, которые в некоторых случаях в принципе нельзя решить.

 

[fixxxer]

А зачем все переписывать? Вполне можно новые фичи делать в виде vue/react-компонентов, которые инициализируются внутри определенного div-а на конкретной странице, а старое оставить как есть.

 

[Yoskaldyr]

С исключительно ui компонентами проблем нет (всякая интерактивность) их можно рендерить на клиенте, проблема возникает с контентными компонентами где SSR обязателен и которые в данный момент рендерятся на php (например хедер страницы, контент страницы, список постов/комментариев и т.д.). Да и важен стейт приложения, чтобы по возможности использовать js навигацию, пуши/вебсокеты и т.д. Например, готовый html, отрендереный на сервере, можно получать через ajax и потом делать регидрацию, но как-то это все очень мутно выглядит и ничего подобного не нашел когда искал.

И еще, насчет использования vue/react компонентов независимо - это будет тоже само что и использование обычных плагинов/компонентов jquery, по отдельности все работает нормально, но все в месте глюкодром. Вся сила vue/react приложений, что это набор вложенных компонентов в компонент приложения, а когда оно все разрозненно - это совсем не то.

 

[fixxxer]

это будет тоже само что и использование обычных плагинов/компонентов jquery

Ну, не то же самое, на том же vue/react писать на порядок проще.

SSR обязателен

Учитывая, как гугл продвинулся в индексации SPA, может, и не так уж обязателен. Но, да, в этом случае либо переделать все на что-то вроде Angular Universal, либо забить. Франкенштейна строить из php, дерьма и палок - вот это как раз и будет глюкодром.

 

[Yoskaldyr]

Учитывая, как гугл продвинулся в индексации SPA, может, и не так уж обязателен.

все не так радужно Продвинуться то продвинулся, но совсем не настолько хотелось бы.

 

[grigori]

А зачем все переписывать? Вполне можно новые фичи делать в виде vue/react-компонентов, которые инициализируются внутри определенного div-а на конкретной странице, а старое оставить как есть.

У меня в этом негативный опыт. Если классический HTML/LESS c jquery интегрировать с react/vue, придется грузить react/vue при переходе на каждую страницу.
Код для разных частей страницы в разных местах лежит, разными утилитами собирается - это тяжело.
Совмещать старый front-end с vue/react проблематично.

 

[fixxxer]

Конечная цель - перейти в итоге целиком на react/vue. Это такое промежуточное состояние. Все сразу не перепишешь, а писать что-то новое на jquery - никаких противорвотных средств не хватит.

Грузить - не проблема, в кэш сляжет, если с заголовками не накосячить. Да можно и не грузить, можно JS-ом обвесить все ссылки и формы, обновлять URL через HTML5 history api, забирать HTML аяксом и обновлять аккуратненько (но тут, да, JS должен быть написан тоже аккуратно и подчищать за собой, иначе все распухнет).

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

 

[Adelf]

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

у меня на проекте не разобрались. и для каждого компонента свой сборщик со своим packages.json и node_modules
это ужасно.

 

[fixxxer]

Да что ты уже год почти мучаешься, смени проект, это не так больно.

 

[Adelf]

я редко там с фронтом контачу. так что все ок