Переход между крупными версиями библиотеки сопровождался переработкой внутренних механизмов обработки масок, что привело к изменению поведения в ряде сценариев. Основная цель эволюции — повышение предсказуемости ввода, устранение неоднозначностей в парсинге масок и унификация API для различных окружений (браузер, фреймворки, SSR).
Одним из ключевых изменений стало изменение внутреннего цикла обработки событий ввода. Ранее логика была тесно привязана к последовательности DOM-событий, что приводило к различиям между браузерами. В новых версиях введён единый слой нормализации ввода:
keydown, input,
pasteСледствием стало то, что некоторые сценарии «постепенного заполнения» маски начали вести себя иначе, особенно при автозаполнении и вставке текста.
Ранее допустимые конструкции масок интерпретировались более гибко, что иногда приводило к неоднозначным результатам. В обновлённой модели:
Например, конструкции с необязательными сегментами теперь требуют более явного описания, иначе поведение считается неопределённым.
Особенно заметны изменения в обработке:
В рамках эволюции Inputmask были удалены или заменены ряд конфигурационных параметров, которые ранее считались устаревшими.
Типовые изменения:
Особенность миграции заключается в том, что старые параметры не всегда приводили к ошибке — в некоторых случаях они просто игнорировались, что усложняло диагностику.
Существенные изменения затронули события, которые генерирует библиотека:
oncomplete,
onincomplete, onclearedВ старых версиях события могли содержать частично «сырые» значения поля. В новых версиях все значения проходят через финальную нормализацию маски.
Также изменилось поведение при программном изменении значения поля:
.setValue() больше не инициирует полный цикл
пользовательских событийРанее инициализация часто выполнялась через прямой вызов функции с DOM-элементом. В новых версиях акцент смещён в сторону конфигурационного объекта:
Изменилось также поведение при повторной инициализации на одном и том же элементе:
Одним из наиболее критичных breaking changes стало изменение обработки вставки данных:
Ранее вставка могла частично игнорировать маску при определённых условиях, что приводило к неконсистентным состояниям. Новая модель устранила этот класс ошибок, но изменила поведение существующих интеграций.
Пользовательские определения масок стали более строгими:
undefined как
валидного состоянияТакже изменилось поведение при конфликте правил:
Интеграции с React, Vue и другими библиотеками были переработаны в сторону изоляции состояния:
В результате поведение маски стало более предсказуемым, но потребовало явного управления обновлениями значения.
Декларативная инициализация через HTML-атрибуты также претерпела изменения:
Теперь JavaScript-конфигурация имеет приоритет над HTML-разметкой без возможности частичного слияния в отдельных случаях.
Ранее удаление маски часто означало «очистку поведения», но сохранение части форматирования. В новой модели:
Это изменение критично для динамических интерфейсов, где маска переключается в рантайме.
Отдельное направление breaking changes связано с выравниванием поведения между браузерами:
contenteditableinput[type=number]Некоторые старые обходные пути были удалены, так как больше не соответствуют современным спецификациям DOM.
Миграция между версиями Inputmask обычно затрагивает несколько уровней:
Наиболее частые источники ошибок при переходе:
Изменения архитектуры привели к перераспределению нагрузки:
В старых реализациях часть логики выполнялась синхронно на каждый символ, что приводило к микролагам в сложных масках. Новая модель смещает часть вычислений в предварительную нормализацию.
Ранее некорректные маски могли «молчаливо деградировать», частично работая. Теперь поведение изменено:
Это изменение особенно важно для сложных форм с динамическими масками, где ранее ошибки маскирования могли быть незаметны на ранних этапах разработки.