Haunted опирается на реактивные хуки, предоставляя
шаблон обновления компонентов, схожий с фреймворками, но остающийся в
парадигме Web Components. Основной акцент делается на управлении
переменными через useState, useReducer и
другие хуки, отражающие изменения в DOM без явного контроля над
обновлениями. Это создаёт отличия от традиционного состояния в
пользовательских элементах, где обычно используется прямое присвоение
свойств и вызов this.requestUpdate() или аналогичных
методов.
В обычных веб-компонентах разработчик самостоятельно решает, где хранить данные: в свойствах экземпляра, атрибутах или внешних объектах. Haunted переносит эту ответственность в хук-систему. Каждый вызов хука связан с позицией в компоненте и жизненным циклом его рендера. Это позволяет:
Отличие заключается не только в месте хранения, но и в том, что состояние перестаёт быть произвольной структурой и превращается в часть рендер-функции.
Традиционное состояние в веб-компонентах требует явного контроля обновлений. В Haunted обновление инициируется самим хуком, а библиотека отвечает за повторный рендер. Такой подход минимизирует побочные эффекты: любые изменения состояния синхронно отображаются в DOM, а повторные вызовы рендера остаются детерминированными, поскольку основаны на текущем значении состояния и входных данных.
Ключевым отличием является поток односторонних изменений. Значение состояния изменяется только через установочную функцию, а рендер зависит только от текущих данных. Это исключает непредсказуемые изменения при прямой модификации свойств.
Хуки Haunted учитывают время существования компонента. Состояние создаётся при первом рендере и уничтожается при удалении элемента из DOM. В системах без хуков состояние часто переживает изменения DOM или требует ручного освобождения ресурсов. Haunted связывает состояние с жизненным циклом автоматически, предотвращая утечки данных и отслеживая зависимости.
Особенно заметно отличие при работе с асинхронностью. Использование
useEffect позволяет реагировать на обновления и очищать
эффекты при размонтировании элемента. Это контрастирует с традиционным
подходом, где очистка осуществляется вручную.
В обычном состоянии повторное использование логики требует промежуточных объектов или миксинов. Haunted решает задачу через хуки, разделяющие логику по функциям. Это обеспечивает композицию, а не наследование. Повторное использование состояния становится простым и выразительным: достаточно создать хук и вызвать его внутри компонента.
Важно, что состояние хуков изолировано от остальных частей приложения, пока специально не вынесено наружу. Таким образом библиотека сохраняет локальность данных и предотвращает неявные зависимости.
Хуки создают чёткую границу между данными самого компонента и данными, поступающими через атрибуты или свойства. В классическом подходе такие данные смешиваются, а их обновления обработчик должен отслеживать вручную. Haunted трактует входные данные как параметры рендера, а состояние — как внутреннюю динамическую сущность. Это приводит к более предсказуемому поведению.
Haunted строит рендер вокруг функции компонента. Состояние не отделено от процесса отображения, а включено внутрь него. Такое объединение снижает когнитивные издержки, поскольку невозможно забыть обновить DOM или вызвать перерендер: библиотека делает это автоматически, когда изменяется состояние.
Сравнивая это с традиционным состоянием, можно выделить два принципиальных отличия:
Это переводит модель работы от императивной модификации элементов к декларативному описанию.
Haunted формирует подход, в котором состояние перестаёт быть пользовательской структурой и превращается в часть вычисления интерфейса. Состояние контролируется библиотекой, а обновления DOM становятся детерминированными и реактивными. Такой стиль ближе к современным фронтенд-фреймворкам, но сохраняет достоинства Web Components: инкапсуляцию, нативный жизненный цикл и независимость от экосистемы.