slim => inertiajs + react + vite в code-basics

Саммари по переезду с серверной шаблонизации на slim в code-basics на инерацию с реактом. Если кто пропустил напомню, концепция инерации в том, что она соединяет бек и фронт в классическом стиле для бекенд фреймворков. В экшенах контроллера передаются данные во вьюху, а вместо обычной серверной вьюхи, используется какой-либо фронтенд фреймворк, в моем случае реакт. Инерция концептуально работает как nest.js, но в качестве бека может выступать любой бекенд фреймворк для которого есть адаптер. Ключевые моменты:

* Используется серверный роутинг
* На фронтенде нет стора. Данные идут в пропсы
* По причине описанной выше, нет никакого API

Для меня это уже второе приложение в таком стиле. Сначала была приемка документов для колледжа, в разработке которой я участвовал три месяца. Теперь вот code-basics. В отдаленной перспективе, я планирую переводить на эту схему сам Хекслет.

Что хочу сказать. Изменения, которые надо вносить в бек для работы с инерцией минимальны. Главное отличие от рельсового подхода наверное в том, что если валидация не прошла, то инерции нужен редирект, а не рендеринг шаблона, как это принято в рельсе. Для этого адаптер инерции под рельсу идет с нужными хелперами, так что тут проблем нет.

Чуть усложнился проброс данных на фронтенд. В бекенде в шаблон можно передавать сами модели, так как это все происходит на сервере. На клиент уйдет только то, что мы реально будем использовать. В случае же инерции, данные целиком уходят на фронтенд, поэтому появляется промежуточный слой DTO, что вполне себе классика для большинства экосистем. В любом случае такой слой всегда присутствует при наличии API.

Либа для ресурсов (DTO), как и полагается в современном мире, умеет генерировать типы для TS, что очень помогает не дублировать и не описывать все ручками.

Лейаутинг и паршиалы на сервере, это особый механизм внутри шаблонизатора. С переходом на фронт, все это стало не актуально и самое главное, для этого ничего не нужно специального. Лейаут в реакте это просто компонент в который мы все оборачиваем. Да чуть больше кода в каждом конретном шаблоне, но явность тоже имеет свои плюсы.

Рельса предоставляет много удобных механизмов для серверных шаблонов, например офигенные формы, которые умеют работать с моделями. Это автоматизирует кучу вещей, от правильной обработки ошибок, интеграцию с i18n и многое другое. В новой схеме все это пришлось заводить руками. Инерция поставляется с хуками для обработки форм, но им далеко до рельсовых интеграций, поэтому пришлось напилить файл с формами. Для хранения строк я взял i18next, но сделал хитро. Я не стал дублировать и переносить переводы из бека, а заюзал либу, которая автоматом собирает все в json для фронта. Поэтому сами тексты описываются как обычно, но “магически” оказываются на фронтенде.

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

А что по внешнему виду? Тут многие знают что я предпочитаю бутстрап, но честно говоря, у меня была попытка найти что-то такое же высокоуровневое. В итоге из более менее подходящего оказался только https://primereact.org/, который можно подстраивать под свои стили. Сейчас в проекте часть компонентов взята из react-bootstrap, часть из primereact, например автокомплит или грид в админке.

Ну и нельзя не сказать про ssr. Так бы он и нафиг не сдался, но для проекта критично SEO, поэтому пришлось заводить. Плюс один процесс в продакшене + настройка + пришлось разбираться с кучей либ, которые не работают в беке.

Помимо этого было еще много мелкой возни с пейджингом, фильтрацией, флешами, событиями для аналитики и бог знает чем еще. Но, в итоге, после первоначальной настройки, я чувствую, что скорость разработки приблизилась к тому, как это было на rails. Да не так быстро, но зато значительно упростилась возможность добавлять любой фронтендовый интерактив. В классическом беке подключать фронт это та еще история.

Ссылки: Телеграм | Youtube | VK