Старый добрый серверный рендеринг

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

Далее я приведу несколько простых примеров использования разработанной мною библиотеки для серверного рендеринга GOSSR for Kotlin и немного деталей её реализации.

Шаблонизатор состоит из двух модулей:

• Собственно сам шаблонизатор, который умеет “рендерить” html теги и атрибуты, умеет форматировать дату/время и числа. Этот модуль не имеет зависимостей - только kotlin-stdlib & reflect что позволяет его очень легко прикрутить к любому фреймворку.

• Обвязка для Spring - реализация org.springframework.web.servlet.View и поддержка строго-типизированных “маршрутов” (routes) для удобного составления href-ссылок и html-форм. Об этом чуть ниже.

Вот самый простой MVC HelloWorld:

@Controller
class GossrExamplesController {
    @GetMapping("hello-world")
    fun helloWorldPage() = HelloWorldPage()
}

  ...

class HelloWorldPage : GossRenderer(), GossrSpringView {
    // точка входа отрисовки страницы
    override fun draw() {
        DIV("any-class") {
            +"Hello World"
        }
    }
}

Данный пример отдаёт браузеру DIV тэг с текстом Hello World внутри. HelloWorldPage класс реализует (через GossrSpringView) спринговый интерфейс View и собственно через него происходит рендеринг. Вот чуть более сложный пример:

    // контроллер
    @GetMapping("users")
    fun usersPage(): View {
        val usersList = getUsersFromDatabase()
        return UsersListPage(usersList)
    }

abstract class DemoGossrRenderer : GossRenderer(), GossrSpringView

// View
class UsersListPage(
    val users: List<UserInfo>
) : DemoGossrRenderer() {

    // точка входа отрисовки страницы
    override fun draw() {
        TABLE {
            classes("table-class")
            
            usersListTableHead()

            TBODY {
                users
                    .sortedBy { it.birthDay } // почему бы не отсортировать на стороне View?
                    .forEach {
                        userRow(it)
                    }
            }
        }
    }

    // метод отрисовки отдельной строки таблицы с информацией о пользователе
    private fun userRow(u: UserInfo) {
        TR {
            TD { +u.firstName }
            TD { +u.lastName }
            TD { +formatDate(u.birthDay) }
            TD { +u.email }
        }
    }

    // метод отрисовки заголовка таблицы
    private fun usersListTableHead() {
        THEAD {
            TR {
                TH { +"First Name" }
                TH { +"Last Name" }
                TH { +"Birth Date" }
                TH { +"Email" }
            }
        }
    }
}

Думаю идея понятна:

• Теги рисуем большими буквами

• атрибуты - кэмл-кейс

• вывод текста через оператор +

• Модель/данные в параметрах View класса

Из неочевидных особенностей:

• Большинство функций-тегов объявлены как inline, отчего во время рендеринга не создаются лишние экземпляры колбеков которые рисуют тело тега

• открытие нового тега обвязано в try..catch что не позволяет одному виджету случайно сломать рендеринг всей страницы

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

Не хочу перегружать читателя примерами использования, но просто представьте всю силу Kotlin — работу со списками, null-safe операции, рефакторинг, быстрый поиск и прыжки по функциям и бессчётное количество других киллер-фич — и всё это доступно в html-шаблонизаторе.

Строгая типизация ендпоинтов

Другой, хотя и связанной с рендеригом головной болью любого full-stack разработчика является слежение за ссылками, параметрами в ендпоинтах и формами. К сожалению, эта часть кода во многих случаях продолжает работать на строках (название параметров, сами URI), что несомненно увеличивает время на поддержку, вероятность ошибок во время внесения обновлений и сильно осложняет навигацию и поиск of usages.

Для упрощения работы с html-ссылками и формами модуль GOSSR-Spring предлагает концепцию routes. Как это работает:

• Любой endpoint - это класс, наследующий интерфейс Route

• На данный момент есть два типа роутов - GetRoute, PostRoute и MultipartPostRoute

• Параметры ендпоинта - это объявленные переменные данного класса

• Учитывая тот факт, что Spring по-умолчанию поддерживает такие названия параметров как например list[index].field или map[key], а так же если один параметр передаётся несколько раз — Spring умеет составлять из начений List или массив — всё это позволяет создавать довольно сложные многоуровневые классы-роуты например для сложных форм

В качестве примера приведу работу с обычными ссылками:

    // класс-route, определяющий GET-endpoint с одним параметром - ID пользователя
    data class UsersInfoRoute(val userId: Long) : GetRoute
    ....
    // код Контроллера:

    @RouteHandler
    // метод обработки запроса
    fun userInfoPage(route: UsersInfoRoute) = UserInfoPage(
        getUserById(route.userId)
    )

// тот же пример страницы со списком пользователей:
    TD {
        A {
            // URI будет автоматически составлен из названия класса
            // в данном случае будет что-то типа:
            // /users/info?userId=123
            href(UsersInfoRoute(u.id))
            +u.email
        }
    }

С таким подходом у вас больше не окажется подвисших ссылок, или неверных параметров, или отсутствие обязательных параметров. Вы всегда сможете найти из каких мест у вас есть переход по ссылке, всегда сможете легко что-то отрефакторить, добавить, поменять. Это невероятно удобно. Из коробки поддержка дат, enum, чисел, строк, bool, параметров являющихся часть uri-path и многое другое.

Пример формы:

    // определяем endpoint для сохранения данных о пользователе
    data class UserSaveRoute(
        // параметры формы
        val userId: Long,
        val firstName: String,
        val lastName: String,
        val email: String,
    ): PostRoute // это будет Post запрос
...
    // контроллер:
    @RouteHandler
    fun saveUser(route: UserSaveRoute): String {
        // сам endpoint
        // все данные из формы доступны в переменной route
        saveUserToDatabase(route.userId, route.firstName, route.lastName, route.email)
        // используем другой route для редиректа на список пользователей
        return redirect(UsersListRoute())
    }

// страница-форма с пользовательскими данными
class UserInfoPage(
    // модель данных, параметр страницы
    val user: UserInfo,
) : DemoGossrRenderer() {

    override fun draw() {
        // создаём route с исходными данными
        // на основе его будет отрисованна html-форма, примерно такая:
        // <form method="POST" action="/user/save">...
        FORM(GossrExamplesController.UserSaveRoute(
            userId = user.id,
            firstName = user.firstName,
            lastName = user.lastName,
            email = user.email
        )) { route ->
            // скрытый параметр формы - ID пользователя
            // рендерер сам поймёт какое название и значение должно быть у параметра
            HIDDEN_LONG(route::userId)
            
            DIV {
                +"Имя:"
                INPUT {
                    classes("form-control")                    
                    nameValueString(route::firstName)
                }
            }
            DIV {
                +"Фамилия:"
                INPUT {
                    classes("form-control")
                    nameValueString(route::lastName)
                }
            }
            DIV {
                +"Email:"
                INPUT {
                    classes("form-control")
                    nameValueString(route::email)
                }
            }
            SUBMIT("btn btn-primary", "Сохранить")
        }
    }
}

Как видите в данном примере мне не пришлось придумывать URI для ендпоинта или использовать строковые названия для параметров. Всё это шаблонизатор генерирует самостоятельно. Единственное о чём мне приходится заботится — о передаче всех параметров роута через форму. Как на этапе компиляции проследить за этой полнотой — я не придумал. Но в целом это значительно проще и удобнее чем ручные строки URI и названия параметров.

Если вдруг этот пост дойдёт до публикации, я бы хотел заранее избежать холивара в комментариях относительного того что лучше: server or client -side рендеринг. Для каждой задачи должны быть свои инструменты, наиболее оптимальным образом её решающие. Могу лишь сказать что подобный поход серверного рендеринга имеет ряд существенных плюсов, особенно в случае очень больших проектов и ограничения на ресурс разработчиков.

Желаю всем устойчивого кода и комфортной работы.