Жизненный цикл экземпляра Cleave.js определяется последовательностью состояний объекта маскировщика, начиная с инициализации и заканчивая полным разрушением связей с DOM. В основе модели лежит идея перехвата ввода пользователя и синхронизации «сырого» значения с форматированным представлением без изменения исходного источника данных.
Жизненный цикл начинается с вызова конструктора
new Cleave(...). На этом этапе формируется объект, который
связывает DOM-элемент и набор правил форматирования.
При создании выполняются следующие внутренние операции:
Ключевой момент: на этапе инициализации библиотека не просто «подписывается» на input, а сразу приводит текущее значение поля к заданному формату. Это означает, что уже существующее значение в DOM может быть перезаписано в соответствии с правилами маски.
После первичной инициализации происходит привязка к событиям браузера. Основные события, которые перехватываются:
input — основной канал обработки пользовательского
ввода;keydown — контроль допустимых символов и поведения
клавиш;focus и blur — управление состоянием
поля;copy / paste — обработка вставляемых
данных.На этом уровне формируется реактивная модель: любое изменение значения немедленно проходит через слой форматирования.
Важно, что библиотека не заменяет нативный input, а расширяет его поведение. DOM остаётся источником истины для UI, но логика значения разделяется на две сущности:
Каждое изменение значения проходит через внутренний пайплайн обработки:
На этом этапе важную роль играет алгоритм позиционирования курсора. После каждого преобразования библиотека пытается восстановить логическую позицию каретки, чтобы пользовательский ввод оставался предсказуемым.
Особенность заключается в том, что форматирование выполняется синхронно с вводом, что создаёт эффект «живой маски».
Экземпляр хранит несколько ключевых состояний:
Эти данные позволяют библиотеке определять тип изменения: добавление символа, удаление, вставка или программная модификация значения.
Дополнительно используется механизм сравнения состояний для предотвращения лишних перерисовок. Если новое значение совпадает с предыдущим, обновление DOM пропускается.
Жизненный цикл экземпляра не ограничивается пользовательским вводом. Внешний код может изменять значение программно.
При установке нового значения через API происходит повторный запуск того же пайплайна обработки, что и при вводе:
Это важно для интеграции с фреймворками, где состояние формы может изменяться реактивно (например, при загрузке данных с сервера или при восстановлении черновика формы).
События вставки данных (paste, autofill браузера) обрабатываются отдельно, поскольку они нарушают стандартный поток посимвольного ввода.
На этом этапе:
Особенность жизненного цикла здесь заключается в том, что одно событие может вызвать несколько последовательных обновлений состояния до стабилизации финального значения.
Некоторые версии поведения библиотеки допускают изменение параметров без полного пересоздания экземпляра. Однако архитектурно это реализуется через частичную пересборку внутреннего состояния.
При изменении конфигурации:
Фактически это промежуточное состояние между «живым» экземпляром и его пересозданием.
Экземпляр предоставляет ограниченный набор методов управления жизненным циклом:
destroy() — полное отключение экземпляра;setRawValue() — установка «сырого» значения;getRawValue() — получение неформатированного
значения;setValue() (в зависимости от версии) — установка
отображаемого значения.Каждый из этих методов влияет на состояние объекта по-разному.
Например, setRawValue() запускает форматирование без
имитации пользовательского ввода, тогда как setValue()
может эмулировать полную цепочку обновления.
Финальная стадия жизненного цикла наступает при вызове
destroy().
В этот момент выполняются следующие операции:
После уничтожения объект перестаёт реагировать на изменения DOM. Важно, что сам input остаётся в документе, но теряет всю дополнительную логику форматирования.
Это критично в SPA-приложениях, где компоненты часто монтируются и размонтируются повторно.
После уничтожения экземпляра возможно создание нового объекта на том же DOM-элементе. В этом случае жизненный цикл начинается заново:
При этом старое состояние полностью изолируется и не влияет на новый экземпляр.
Одной из ключевых характеристик жизненного цикла является постоянная синхронизация между тремя слоями:
Любое рассогласование между этими слоями немедленно исправляется при следующем событии ввода или программного обновления. Это создаёт модель «самовосстанавливающегося» состояния, где DOM никогда не остаётся в неконсистентном виде надолго.
В процессе жизненного цикла могут возникать повторные триггеры обновления, особенно при:
Для контроля стабильности используются механизмы сравнения предыдущего и нового состояния, а также подавление повторных событий внутри одного цикла обновления.
Эта защита предотвращает бесконечные циклы перерисовки и обеспечивает предсказуемость поведения даже при нестандартном вводе.