Telegram Group & Telegram Channel
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



group-telegram.com/orgprog/278
Create:
Last Update:

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

BY Организованное программирование | Кирилл Мокевнин




Share with your friend now:
group-telegram.com/orgprog/278

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

NEWS Oh no. There’s a certain degree of myth-making around what exactly went on, so take everything that follows lightly. Telegram was originally launched as a side project by the Durov brothers, with Nikolai handling the coding and Pavel as CEO, while both were at VK. The War on Fakes channel has repeatedly attempted to push conspiracies that footage from Ukraine is somehow being falsified. One post on the channel from February 24 claimed without evidence that a widely viewed photo of a Ukrainian woman injured in an airstrike in the city of Chuhuiv was doctored and that the woman was seen in a different photo days later without injuries. The post, which has over 600,000 views, also baselessly claimed that the woman's blood was actually makeup or grape juice. DFR Lab sent the image through Microsoft Azure's Face Verification program and found that it was "highly unlikely" that the person in the second photo was the same as the first woman. The fact-checker Logically AI also found the claim to be false. The woman, Olena Kurilo, was also captured in a video after the airstrike and shown to have the injuries. At its heart, Telegram is little more than a messaging app like WhatsApp or Signal. But it also offers open channels that enable a single user, or a group of users, to communicate with large numbers in a method similar to a Twitter account. This has proven to be both a blessing and a curse for Telegram and its users, since these channels can be used for both good and ill. Right now, as Wired reports, the app is a key way for Ukrainians to receive updates from the government during the invasion.
from sg


Telegram Организованное программирование | Кирилл Мокевнин
FROM American