Как стать автором
Обновить

Комментарии 11

Идея в том, что компонент рендерится на сервере, а значит он имеет доступ ко всему серверному слою. Это значит, что можно делать запросы к бд прям в нем, я не включил это в статью, но в гитхабе можно увидеть как легко сделать серверные компоненты асинхронными

Ещё 15 лет назад ржали с однйо софтины в которой в в обработчики клика кнопки в базу ходили чтоб табличку нарисовать. Уже тогда все понимали что это плохо. Ксати, почему бы не отправить клиенту целиком docker образ с сервером и запустить его на JsLinux?

Интересно. Но команда Реакта так же работает над чем-то похожим, советую ознакомиться с server side components

Ох, простите, просмотрел.

Зачем сериализовать компонент, если можно сериализовать данные и отрисовать их компонентом, указав его тип. где логика? пример правильного подхода и для всех серверных языков - https://github.com/Claus1/unigui

Ну вообще именно это происходит. По сути всё что надо для сериализации компонента это его пропсы (данные) и тип

Я не совсем понимаю, зачем это. Вот SSR понятно - для поисковиков. А тут что? Лишняя нагрузка для сервера.

Параграф про полезности не слишком убедил. Доступ к серверному слою - это sql запросы прямо из компонента? А код для редактора можно сделать отдельным подгружаемым чанком и не заморачиваться. К тому же раз мы получаем json, то всё равно на клиенте потребуется js для рендеринга.

Как по мне, полезно уже тем, что фронты могут какие-то вещи делать сами. Особенно в проектах, где SPA с кучей логики, а на бэке просто REST.

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

Знаете похоже на что. Берём подарок заваорачиваем его ещё раз ещё и ещё и ещё, новый год всё таки.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации