Насколько грамотно построено взаимодействие между фронтом и бэком?
Добрый день! В компании, в которой работаю, взаимодействие между фронтом (React) и бэком (php, Symfony) построено не через rest api, а несколько странным образом: php отдает данные для рендера страницы, которые записываются через js как глобальное свойство windows. Соответственно, React получает их из windows. Страницы рендерятся, как при обычном взаимодействии с php - есть несколько twig шаблонов, в которые php передает данные, и далее в зависимости от этих данных подгружается тот или иной компонент React. То есть, получается обычное многостраничное приложение, контент которого частично отрисовывается при помощи компонентов React. В чем минусы подобной архитектуры, помимо того, что теряется сам смысл React как фреймворка для создания single page application? В нынешней команде остались лишь бэкенд-разработчики, так что задать вопрос, чем был обусловлен подобный подход, некому.
Именно данные передаются, а не конфигурация? Часто объект виндоу используется для хранения конфига приложения. Данные, наверное, в реактовских приложениях все же лучше фетчить при помощи саг. ИМХО
camelCaseVlad, спасибо, буду читать статьи на тему!
Мой опыт взаимодействия с фреймворками не очень большой, в прежних проектах данные о юзере и т.п. передавались через fetch к бэкенду.
Смысла никакого в этом нет. Это не архитектура а полуфабрикат. Главный вопрос: что хотели получить в итоге?
Судя по описанию - React SSR вместо twig, данные из window - это норм практика, например, для redux-store, возможна оптимизация под СЕО за счет динамического рендеринга части страниц, динамические компоненты.
основная идея SSR - простой рендеринг, рендеринг c последующей динамикой и отложенный рендеринг после загрузки данных, так что если убрать php-twig-react прослойку то все выглядит "хорошо"
Реакт — это не фреймворк для SPA, а библиотека для создания интерфейсов. В крупных и/или старых веб-приложениях, особенно на этапе постепенного внедрения нового стека и перехода на SPA, вполне уместна и практикуется описанная вами схема, когда роутинг реализуется классически через многостраничность, а рендеринг происходит частично на сервере, а частично — на клиенте, причем дорисовываемые на клиенте куски интерфейса ("виджеты") могут быть как компонентами, так и самостоятельными реакт-приложениями (вместо реакта можно подставить любую другую библиотеку/фреймворк). Передавать данные через window тоже нормально, если эти данные уже были сформированы на сервере и использованы для серверного рендеринга.
Сам подход нормальный, и смысл реакта никак не теряется. Более того, некоторые считают подобные вещи более прогрессивным подходом а фреймворки типа Gatsby.js этот подход развивают куда дальше чем описанное у вас.
Грамотно это у вас сделано или нет - зависит от того как сделано.
Если в window кладутся просто настройки типа языка и прочего - то тут вообще сложно что-то криво сделать.
с условной загрузкой компонент в зависимости от роута на сервере тоже нет проблем если сделано хорошо
