Система событий в Slim Select строится вокруг набора жизненных циклов компонента и реакций на пользовательские действия, которые преобразуются в предсказуемые callback-вызовы. Архитектура ориентирована на минимализм: вместо сложной событийной шины используется конфигурация, где поведение задаётся при инициализации экземпляра, а затем исполняется синхронно в ответ на изменения состояния.
При создании селекта формируется внутреннее состояние, отражающее текущий набор опций, выбранные значения, состояние выпадающего списка и параметры поиска. На каждом этапе этого жизненного цикла предусмотрены контрольные точки, через которые проходит управление:
Каждая из этих точек может быть перехвачена через конфигурационные callback-функции, которые передаются при инициализации экземпляра Slim Select.
Ключевым событием выступает изменение выбора. Оно возникает при добавлении или удалении значения пользователем, а также при программной модификации состояния.
В конфигурации это обычно представлено через callback, принимающий актуальный массив выбранных значений. Его основная особенность заключается в том, что он всегда возвращает полное состояние выбора, а не дельту изменений.
Такой подход упрощает синхронизацию с внешними системами:
Важно учитывать, что изменение может быть вызвано как пользовательским действием, так и API-вызовом, поэтому обработчик должен быть идемпотентным.
Состояние выпадающего списка является отдельной частью внутренней модели. Оно контролируется через два основных события:
Открытие списка обычно связано с фокусировкой поля ввода или кликом по контейнеру компонента. В этот момент библиотека переводит интерфейс в активное состояние, подготавливает список опций и, при необходимости, запускает механизм фильтрации.
Закрытие списка происходит при потере фокуса, выборе элемента или программном вызове. На этом этапе Slim Select завершает визуальные анимации и фиксирует текущее состояние выбора.
Оба события часто используются для интеграции с внешним UI:
Поисковая подсистема Slim Select активируется при вводе текста в поле фильтрации. Каждое изменение строки поиска формирует событие, которое передаётся в callback поиска.
Поведение поиска включает несколько этапов:
Callback поиска позволяет переопределить стандартную логику фильтрации. Это особенно важно при работе с большими наборами данных или серверной подгрузкой.
Возможны два режима:
Клиентский поиск Логика фильтрации выполняется внутри библиотеки. Callback используется только для наблюдения за вводом.
Внешний поиск Callback перехватывает строку и передаёт управление внешнему источнику данных (например, API), после чего список опций обновляется вручную.
В режиме множественного выбора система дополнительно отслеживает операции добавления и удаления отдельных элементов. Эти операции являются частными случаями изменения общего состояния, но могут быть выделены в отдельные логические события.
Добавление значения происходит при выборе нового элемента из списка. Удаление — при снятии выбора или использовании интерфейсных элементов удаления (например, крестика у тега).
Такая детализация позволяет:
Отдельный слой событийной модели связан с программным управлением. Slim Select предоставляет API для изменения состояния без участия пользователя, и эти изменения также проходят через стандартный цикл событий.
Типичные операции:
При этом важно, что такие изменения не обходят систему событий, а проходят через неё, обеспечивая консистентность поведения между пользовательскими и программными действиями.
При одновременном возникновении нескольких событий Slim Select использует строгую последовательность обработки. Например, при выборе элемента:
Такая последовательность гарантирует, что внешний код всегда получает уже согласованное состояние, а не промежуточные данные.
Хотя Slim Select не опирается напрямую на нативную событийную модель DOM как основную, он всё же взаимодействует с ней через базовые события:
Эти события служат триггерами для внутренних механизмов, которые затем преобразуются в высокоуровневые callback-вызовы. Такой слой абстракции позволяет скрыть различия между браузерами и упростить API библиотеки.
При интеграции с серверными источниками данных система событий приобретает асинхронный характер. Особенно это заметно в сценариях удалённого поиска, где каждое изменение строки ввода может инициировать запрос.
Для таких случаев важно учитывать:
Slim Select в подобных сценариях опирается на актуальность последнего введённого значения, игнорируя устаревшие ответы, если они приходят после обновления состояния.
Событийная модель библиотеки предполагает, что каждый callback может вызывать внешние побочные эффекты. Это может приводить к цепочкам реакций, особенно при связке нескольких компонентов.
Типичные меры контроля:
Такая дисциплина особенно важна при использовании Slim Select в сложных интерфейсах, где один селект может влиять на состояние других компонентов.
В основе всей системы событий лежит принцип синхронности состояния: любое событие отражает уже завершённое изменение внутренней модели. Это означает, что callback-функции всегда получают актуальные данные, а не промежуточные этапы обработки.
Такой подход снижает вероятность ошибок синхронизации и упрощает интеграцию библиотеки в реактивные фреймворки и архитектуры, основанные на потоках данных.