Изменения в API

Одно из ключевых изменений в API Slim Select связано с переходом от упрощённой инициализации к более структурированному объекту конфигурации. Ранее поведение библиотеки часто зависело от минимального набора параметров, где основной акцент делался на передаче селектора и базовых опций. В актуальной модели инициализации акцент смещён в сторону явной конфигурации всех аспектов поведения.

Инициализация теперь строится вокруг конструктора:

const select = new SlimSelect({
  select: '#my-select',
  settings: {
    placeholderText: 'Выбор значения'
  }
});

Изменение заключается не только в форме передачи параметров, но и в логике их группировки. Появилось чёткое разделение на конфигурацию поведения (settings), данные (data) и системные параметры.

Переход от HTML-инициализации к программному управлению

В ранних подходах значительная часть поведения могла задаваться через HTML-атрибуты стандартного <select>. В обновлённом API Slim Select этот подход считается вспомогательным. Основной источник истины переносится в JavaScript-конфигурацию.

Особенно заметно это в следующих аспектах:

  • атрибут data-placeholder больше не является основным способом задания плейсхолдера;
  • disabled-логика централизована в API;
  • обработка кастомных опций полностью выносится в JS-слой.

Это изменение влияет на архитектуру приложений: теперь состояние селекта определяется не DOM-атрибутами, а экземпляром библиотеки.

Изменение структуры настроек settings

Объект settings претерпел переработку в сторону более строгой группировки параметров. Ранее параметры могли передаваться на верхнем уровне конфигурации, что приводило к размытию ответственности. В новой модели:

  • визуальные параметры отделены от логики данных;
  • текстовые настройки сгруппированы отдельно;
  • параметры поиска и фильтрации вынесены в специализированные секции.

Пример обновлённой структуры:

const select = new SlimSelect({
  select: '#my-select',
  settings: {
    placeholderText: 'Выберите значение',
    searchPlaceholder: 'Поиск...',
    allowDeselect: true
  }
});

Изменение API в этой области направлено на снижение конфликтов имён и упрощение расширяемости.

Работа с данными: переход к явной модели data

Одним из наиболее значимых изменений стала переработка способа подачи данных. Ранее данные часто передавались через DOM или через упрощённые массивы строк. Теперь структура данных стала объектной и строго типизированной по смыслу.

Современный формат:

data: [
  { text: 'Первый элемент', value: '1' },
  { text: 'Второй элемент', value: '2' }
]

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

Дополнительно появилась возможность расширять структуру объекта:

{
  text: 'Москва',
  value: 'moscow',
  disabled: false,
  data: {
    region: 'RU'
  }
}

Таким образом API стал ближе к модели данных, используемой в современных UI-фреймворках.

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

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

Установка выбранного значения

Ранее:

select.set('2');

Теперь:

select.setSelected('2');

Разделение методов позволяет явно различать операции:

  • setSelected — установка выбранного значения;
  • setData — замена набора данных;
  • set (в устаревших версиях) — универсальный метод, который больше не рекомендуется использовать.

Обновление данных без пересоздания экземпляра

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

select.setData([
  { text: 'A', value: 'a' },
  { text: 'B', value: 'b' }
]);

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

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

Система событий была переработана для унификации и предсказуемости. Ранее события могли зависеть от внутренних реализаций и различаться по структуре. В обновлённой версии введена единая схема передачи данных события.

Пример подписки:

select.on('change', (info) => {
  console.log(info.value);
});

Структура объекта события стала более стабильной и включает:

  • текущее значение;
  • массив выбранных значений (для multi-select);
  • метаданные изменения.

Отдельное внимание уделено отказу от «неявных» событий, которые могли срабатывать без явного пользовательского действия.

Переход от DOM-ориентированного API к экземплярному

Существенное изменение архитектуры API связано с отказом от глобального управления через DOM-запросы. Теперь каждый экземпляр Slim Select полностью изолирован.

Ранее возможно было обращение к элементу через глобальные методы:

SlimSelect.destroy('#my-select');

Теперь управление осуществляется только через экземпляр:

const select = new SlimSelect({ select: '#my-select' });
select.destroy();

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

Переработка destroy и очистки ресурсов

Метод уничтожения экземпляра стал более строгим. Помимо удаления DOM-обвязки теперь гарантированно:

  • удаляются все подписки на события;
  • очищаются внутренние кеши;
  • восстанавливается исходный <select> в корректное состояние.
select.destroy();

Важное изменение заключается в том, что повторная инициализация после destroy теперь рассматривается как полностью новая операция без наследования состояния.

Изменения в фильтрации и поиске

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

settings: {
  searchText: 'Поиск',
  hideSelected: true
}

Также изменена модель поведения поиска:

  • фильтрация теперь применяется к объекту данных, а не к DOM-элементам;
  • добавлена поддержка кастомной логики сравнения;
  • улучшена работа с регистронезависимым поиском.

Поддержка асинхронных данных

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

fetch('/api/options')
  .then(res => res.json())
  .then(data => {
    select.setData(data);
  });

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

Устаревшие методы и их замена

С переходом к новой архитектуре ряд методов был объявлен устаревшими. Основные замены:

  • set() → setSelected()
  • прямое изменение DOM → setData()
  • глобальные методы управления → экземплярные методы
  • частичная инициализация через HTML → конфигурация через JS

Удаление этих возможностей направлено на уменьшение количества скрытых состояний и упрощение отладки.

Изменения в multi-select API

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

select.setSelected(['1', '2']);

Это изменение устраняет различие между single-select и multi-select на уровне API, оставляя различия только в конфигурации.

Стабилизация поведения экземпляра

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

Это влияет на:

  • предсказуемость UI;
  • тестируемость компонентов;
  • интеграцию с фреймворками (React, Vue, Angular через обёртки).

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

Оглавление