Введение в HTMX: динамический HTML без JavaScript

HTMX позволяет использовать расширенный синтаксис HTML вместо JavaScript для достижения интерактивности. HTMX обеспечивает взаимодействие HTTP непосредственно в разметке и поддерживает множество других интерактивных потребностей без использования JavaScript. Это интересная идея, которая может в конечном итоге повлиять на работу веб-интерфейсов. Давайте посмотрим, как используется HTMX и что делает его таким привлекательным.

Что такое HTMX?

HTMX существует уже некоторое время, но это был своего рода спящий проект. Его недавнее принятие в акселератор GitHub может все изменить. Основная идея состоит в том, чтобы взять общие случаи использования, требующие шаблонного взаимодействия JavaScript и HTML, и просто использовать синтаксис HTML без JavaScript. Многие взаимодействия с HTMX становятся декларативными.

Это уже звучит многообещающе, не так ли? Каждый веб-разработчик знает, что существуют много распространенные шаблонные случаи. Карсон Гросс, создатель HTMX, говорит, что надеется «завершить HTML как гипертекст, повысив его выразительность настолько, чтобы сделать его конкурентоспособной альтернативой более продвинутым современным веб-приложениям».

Чтобы получить быстрое представление, посмотрите эту демонстрацию HTMX. По сути, мы нажимаем кнопку, чтобы разрешить редактирование полей пользовательского объекта. Данные на самом деле PUT в серверную конечную точку. Демонстрацию можно увидеть на рисунке 1. Обратите внимание на сетевое взаимодействие в нижнем кадре после нажатия кнопки Показывать.

ИДГ

Обычно для всего этого требуется какой-то JavaScript, независимо от того, какой фреймворк вы используете. HTMX превращает взаимодействие в два фрагмента разметки: один для пользовательского интерфейса отображения и один для пользовательского интерфейса редактирования, как показано в листинге 1.

Листинг 1. Обновление пользователя в HTMX

<div hx-target="this" hx-swap="outerHTML">
    <div><label>First Name</label>: Joe</div>
    <div><label>Last Name</label>: Blow</div>
    <div><label>Email</label>: joe@blow.com</div>
    <button hx-get="/contact/1/edit" class="btn btn-primary">
    Click To Edit
    </button>
</div>
<!-- The edit: -->
<form hx-put="/contact/1" hx-target="this" hx-swap="outerHTML">
  <div>
    <label>First Name</label>
    <input type="text" name="firstName" value="Joe">
  </div>
  <div class="form-group">
    <label>Last Name</label>
    <input type="text" name="lastName" value="Blow">
  </div>
  <div class="form-group">
    <label>Email Address</label>
    <input type="email" name="email" value="joe@blow.com">
  </div>
  <button class="btn">Submit</button>
  <button class="btn" hx-get="/contact/1">Cancel</button>
</form>

Если вы посмотрите на разметку в листинге 1, то легко увидеть, что происходит: hx-swap Свойство предоставляет HTML для div прежде чем он будет отредактирован, и outerHTML сообщает платформе, как она связана с динамическим содержимым внутри. Редактируемая версия представляет собой элемент формы, содержащий x-put свойство, которое идентифицирует PUT HTML-метод и какую конечную точку использовать.

Возникает вопрос, как HTMX достигает этого «обмена» и последующего PUT без использования JavaScript? Ответ прост: он использует рендеринг HTML на стороне сервера для разметки редактирования и абстрагирует маршалинг формы в инфраструктуру. JavaScript все еще работает «за кулисами». По сути, мы получаем более детальный синтаксис HTML, который может просто загружать сегменты вместо целых страниц и отправлять запросы Ajax.

Это интересный пример применения принципа DRY. Даже в чем-то вроде React существует определенное количество шаблонного кода, который перемещает информацию из одной формы в другую. Конечно, HTMX не устранил это полностью, но перенес всю работу на сервер.

Серверный HTMLMX

Теперь давайте рассмотрим серверную часть уравнения. Существуют примеры многих серверных технологий, использующих HTMX, поскольку, как говорит Гросс, HTMX «независим от серверной части». Ему не важно, какую серверную часть вы используете, лишь бы она создавала HTML». Чтобы понять, как это работает, давайте рассмотрим пример TODO, в котором используется Express вместе с механизмом шаблонов HTML Pug. Этот пример представляет собой реализацию классического приложения TODO.

Для начала существующие задачи выводятся из Express с помощью команды:

res.render('index', { todos: filteredTodos, filter, itemsLeft: getItemsLeft() });

Эта команда использует коллекцию задач в памяти и отображает их с помощью шаблона Pug в обычном формате, за исключением того, что он включает специальный hx- свойства, управляющие взаимодействием HTMX. Например, форма для POST новые задачи показаны в листинге 2.

Листинг 2. Форма POST со свойствами HTMX

form(hx-post="/todos", hx-target="#todo-list", hx-swap="afterbegin", _="on htmx:afterOnLoad set #txtTodo.value to ''")
  input#txtTodo.new-todo(name="todo",placeholder="What needs to be done?", autofocus="")

Здесь вы можете увидеть, как afterbegin Атрибут работает для размещения нового контента там, где ему место в списке. on htmx сценарии — это пример Hyperscript, своего рода упрощенного языка сценариев. Он часто используется с HTMX, но не является строго частью HTMX и не является обязательным для его использования. По сути, on htmx здесь используется для обработки установки значения формы ввода после создания новой задачи.

В качестве другого примера в листинге 3 показан шаблон Pug для редактирования списка дел.

Листинг 3. Редактирование серверного шаблона в Pug

form(hx-post="/todos/update/" + todo.id)
  input.edit(type="text", name="name",value=todo.name)

В листинге 3 в разметке используется hx-post свойство, указывающее, куда отправлять JSON для отредактированной задачи. Вывод из этих примеров заключается в том, что я отметил ранее: сервер отвечает за предоставление HTML (украшенного тегами HTMX) фрагментами нужного размера для заполнения различных частей экрана, которые необходимы интерфейсу для различных взаимодействий. Клиент HTMX разместит их там, где они должны быть, в зависимости от свойств. Он также будет обрабатывать отправку соответствующих данных для использования службами.

Конечные точки, ответственные за получение данных, могут работать как обычные конечные точки, с тем отличием, что ответом должен быть необходимый HTMX. Например, в листинге 4 вы можете увидеть, как сервер Express обрабатывает POST чтобы создать новую задачу.

Листинг 4. Обработка создания задач

app.post('/todos', (req, res) => {
  const { todo } = req.body;
  const newTodo = { 
    id: uuid(),
    name: todo, 
    done: false 
  };
  todos.push(newTodo);
  let template = pug.compileFile('views/includes/todo-item.pug');
  let markup = template({ todo: newTodo});
  template = pug.compileFile('views/includes/item-count.pug');
  markup  += template({ itemsLeft: getItemsLeft()});
  res.send(markup);
});

Листинг 4 представляет собой типичный POST обработчик тела, который принимает значения из данных формы и создает с их помощью новый бизнес-объект (newTodo). Однако затем он использует значения для заполнения шаблона Pug и отправляет их обратно клиенту для использования в качестве вставки в шаблон. Todo список на лицевой стороне.

Другие примеры серверных технологий включают использование HTMX вместе с Spring Boot с Thymeleaf в мире Java и Spring Boot с Django в мире Python.

Создание шаблонов на стороне клиента с помощью HTMX

Вариант этого шаблона, поддерживаемый HTMX, использует шаблон на стороне клиента. Это уровень, который запускается на клиенте, принимает JSON от сервера и выполняет там перевод разметки. Когда я спросил Гросса об использовании службы RESTful с JSON, он ответил, что это возможно с помощью шаблонов на стороне клиента, но с оговоркой, что REST обычно понимают неправильно.

Тогда возникает обратный вопрос: как мы можем отправить JSON на сервер вместо кодировки формы по умолчанию? И снова для этого есть расширение; а именно JSON-ENC.

Убедительный подход к веб-взаимодействию

Размышления о HTMX сразу вызывают массу мыслей. В результате идея так же полезна, как и сам проект. HTMX как зрелый проект, возможно, не будет работать так, как сегодня, но он уже доказал свою полезность. Наиболее привлекательной является идея обработки всех этих очень распространенных запросов в стиле Ajax, что обычно означает использование fetch() или что-то подобное, используя только свойство HTML. Это проще и чище, и все хранится в одном месте. Очевидно, что делает разметка.

У меня более неоднозначное отношение к созданию разметки на стороне сервера. Разработчики так привыкли иметь дело с JSON для этой цели; внесение разметки просто добавляет шаг к созданию клиента. Мы видели множество подходов на стороне сервера, и они всегда сбивают с толку мощное трио HTML, JavaScript и CSS, которое в конечном итоге продолжает побеждать. Возможно, на этот раз все будет иначе. Это большой маятник, который нужно раскачивать.

Конечно, существует опция шаблонизации на стороне клиента, при которой сервер остается привычным эмиттером JSON. Я попытался представить, как это будет работать в большом программном проекте. Снизит ли это общую сложность масштабного проекта?

У Гросса есть собственное мнение о сложности. Вы можете видеть, как его мысли воплощаются в дизайне HTMX. Эта технология хочет упростить ситуацию, вернув нас к гипертексту как механизму состояний веб-приложений. Этот пример показывает идею в действии. Использование JSON в качестве протокола означает, что клиенты становятся умнее и сложнее, а архитектура становится менее самоописываемой.

Возможно, все это могло бы сработать. Если бы мы избежали внутренней сложности, расширив базовый язык HTML для фактической обработки современных требований, таких как Ajax, мы могли бы вернуться в более простые времена. Разметка снова станет центральным дескриптором данных, которого будет достаточно для описания пользовательского интерфейса, а также данных в сети.