Изменения в API между версиями

В ранних версиях Awesomplete основная точка входа была предельно простой: конструктор new Awesomplete(input, options) принимал DOM-элемент и объект конфигурации, однако поведение значительной части опций было менее формализовано. Со временем интерфейс инициализации стал более строгим и предсказуемым.

Изначально список автодополнения часто задавался через атрибут data-list, поддерживающий строковый формат с разделителями. Позднее приоритет сместился в сторону передачи массива или внешнего источника данных через JavaScript, что позволило унифицировать обработку и упростить динамическое обновление данных без пересоздания экземпляра.

Ключевое изменение заключается в том, что конфигурация перестала рассматриваться как вторичный слой над HTML-атрибутами и стала основным механизмом управления поведением:

• ранний подход: data-list как основной источник данных
• современный подход: options.list как предпочтительный источник
• гибридный режим сохранён для обратной совместимости

Изменения в модели данных списка

Одним из наиболее заметных сдвигов в API стало расширение формата list. В ранних реализациях предполагалось, что элементы списка — это строки. Позже появилась поддержка объектов, что повлекло изменение логики отображения и выбора.

Современная модель допускает:

• строки: базовый сценарий автодополнения
• объекты: расширенные данные (label, value, пользовательские поля)
• функции-генераторы: динамическое формирование списка

Это изменение привело к переработке внутренних механизмов сравнения и фильтрации. Если раньше сопоставление происходило напрямую по строке, то позже появилась нормализация значения через внутренние преобразования, чтобы унифицировать работу со сложными структурами данных.

Фильтрация и сортировка: переход к кастомизируемым стратегиям

Первоначально логика фильтрации была жёстко встроена в библиотеку и использовала простое сопоставление подстроки. Это обеспечивало минимальную гибкость, но максимальную предсказуемость.

Позднее API было расширено за счёт функций:

• filter(text, input) — определяет, подходит ли элемент
• sort(a, b, input) — задаёт порядок отображения
• item(text, input) — формирует DOM-элемент результата
• replace(text) — управляет подстановкой значения в input

Это изменение стало ключевым с точки зрения архитектуры: библиотека перестала навязывать алгоритм подбора и перешла к модели «поведения через переопределение функций».

Ранее подобная кастомизация требовала модификации исходного кода, тогда как новая модель позволила внедрять сложные сценарии (например, приоритетные совпадения, контекстный поиск, семантическую сортировку) без форков.

Изменения в работе с DOM и рендерингом

Ранние версии Awesomplete использовали фиксированную структуру списка результатов, где шаблон элементов был практически неизменяемым. Со временем появилась возможность управлять формированием DOM-узлов через опцию item, что стало важной точкой расширения API.

Изменился и подход к обновлению списка:

• ранее: пересоздание DOM при каждом изменении
• позднее: более точечные обновления и оптимизация перерисовки

Также была усилена изоляция компонентов: библиотека стала меньше зависеть от внешних стилей и структуры страницы, делая поведение более предсказуемым при интеграции в сложные интерфейсы.

Изменения событийной модели

Событийная система претерпела важную эволюцию: от минимального набора триггеров к более структурированному набору событий, отражающих жизненный цикл автодополнения.

Базовые события:

• awesomplete-open
• awesomplete-close
• awesomplete-select

В более поздних версиях акцент сместился на консистентность: события стали более стабильными по поведению и унифицированными по моменту срабатывания. Это снизило количество неоднозначных состояний, например ситуаций, когда список считался открытым, но DOM уже был частично обновлён.

Дополнительно усилилась роль событий как основного механизма интеграции: вместо прямого вмешательства в методы экземпляра стало предпочтительным использовать подписку на события.

Минимальная длина ввода и триггерные условия

Параметр minChars в ранних версиях имел более ограниченную интерпретацию. В ряде сценариев он влиял только на отображение списка, но не на внутреннюю логику подготовки данных.

Позднее поведение было унифицировано: проверка минимального количества символов стала частью единого цикла обработки ввода. Это устранило расхождения между состоянием «данные готовы» и «интерфейс отображает результаты».

Также были уточнены правила обработки пустых строк и пробельных символов, что повысило предсказуемость поведения при очистке input-поля.

Изменения в модели выбора и подстановки значения

Механизм выбора элемента (select) и подстановки значения в input подвергся заметной переработке. Изначально логика подстановки была тесно связана с текстовым представлением элемента списка.

Позднее появилась явная функция replace, которая отделила:

• отображаемое значение в списке
• фактическое значение, вставляемое в input

Это изменение позволило реализовать сценарии, где пользователь видит одно значение (например, «Москва — город»), а в поле вводится другое (например, идентификатор или чистое название).

Также была улучшена обработка клавиатурной навигации: выбор стрелками и подтверждение Enter стали более строго синхронизированы с внутренним состоянием компонента.

Совместимость и деградация API

Одним из ключевых принципов развития Awesomplete стало сохранение обратной совместимости. Вместо удаления устаревших параметров использовалась стратегия постепенного смещения:

• старые параметры продолжают работать
• новые имеют приоритет при конфликте
• устаревшие сценарии помечаются как нежелательные, но не ломаются

Такой подход позволил интеграциям, построенным на ранних версиях, продолжать функционировать без переписывания логики, при этом постепенно переходя на более гибкую модель API.

Изменения в расширяемости и переопределении поведения

В раннем API кастомизация ограничивалась набором параметров. Позднее архитектура сместилась в сторону переопределяемых точек расширения.

Основные точки кастомизации:

• фильтрация
• сортировка
• рендеринг элемента
• подстановка значения

Это изменение фактически превратило библиотеку из фиксированного автокомплита в мини-фреймворк для построения логики подсказок. Разработчик получил контроль над каждым этапом pipeline обработки данных: от ввода до финального значения в input.

Стабилизация внутреннего поведения и предсказуемость API

Поздние изменения в API были направлены не столько на добавление новых возможностей, сколько на стабилизацию существующих. Особое внимание уделялось:

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

Это привело к тому, что API стал менее «экспериментальным» и более детерминированным: одинаковые входные данные стали давать одинаковое поведение независимо от контекста использования.