Событие error

Событие error возникает в Slim Select в момент, когда внутренняя операция компонента завершилась неудачно: чаще всего это связано с загрузкой данных через AJAX, некорректным ответом сервера, ошибками парсинга JSON или проблемами в пользовательских обработчиках, подключённых к жизненному циклу селекта. Это событие относится к механизмам устойчивости компонента и позволяет централизованно реагировать на сбои без необходимости оборачивать каждый вызов Slim Select в собственные конструкции try/catch.

Механизм обработки ошибок

Внутри Slim Select ошибки обычно формируются на уровнях:

  • загрузка данных (remote data / ajax fetch)
  • обработка результата (парсинг, трансформация массива опций)
  • выполнение пользовательских callback-функций
  • взаимодействие с DOM в момент инициализации или обновления

Когда возникает исключение, библиотека не всегда «падает» полностью. Вместо этого она старается завершить текущую операцию и уведомить внешний код через событие error.

Типовой сценарий:

  • вызывается асинхронная загрузка данных
  • сервер возвращает некорректный JSON или HTTP-ошибку
  • Slim Select фиксирует ошибку
  • триггерится событие error с передачей контекста

Подписка на событие error

В Slim Select подписка на события осуществляется через API экземпляра. Обработчик error регистрируется после инициализации компонента:

const select = new SlimSelect({
  select: '
});

select.on('error', (error) => {
  console.log('Ошибка Slim Select:', error);
});

Колбэк получает объект ошибки, структура которого зависит от источника сбоя. Обычно он содержит:

  • message — текстовое описание ошибки
  • type — тип ошибки (network, parse, runtime)
  • stack — стек вызовов (если доступен)
  • context — дополнительная информация о состоянии компонента

Ошибки при AJAX-загрузке

Наиболее частый источник события error — динамическая загрузка данных через ajax. При использовании удалённых источников Slim Select выполняет запрос и ожидает массив данных в определённом формате.

Пример конфигурации:

const select = new SlimSelect({
  select: '#remote',
  ajax: (search, callback) => {
    fetch(`/api/items?q=${search}`)
      .then(res => res.json())
      .then(data => {
        callback(data);
      })
      .catch(err => {
        select.trigger('error', err);
      });
  }
});

При сбое сети или неверном формате ответа управление передаётся в error.

Типовые причины:

  • HTTP 500 или 404
  • отсутствие CORS-заголовков
  • неожиданный формат ответа (не массив)
  • таймаут запроса
  • прерывание запроса пользователем

Ошибки парсинга данных

Slim Select ожидает строгую структуру элементов:

[
  { text: 'Option 1', value: '1' },
  { text: 'Option 2', value: '2' }
]

Если вместо этого приходит:

  • null
  • объект вместо массива
  • строка JSON, не распарсенная в объект
  • массив с отсутствующими ключами text или value

внутренний парсер может сгенерировать исключение, которое также попадёт в error.

Пример ситуации:

select.setData("invalid data");

Результат — триггер события error с описанием невозможности построить список опций.

Runtime-ошибки в пользовательских callback

Slim Select позволяет подключать пользовательские функции на разных этапах жизненного цикла. Например, форматирование опций или фильтрация:

new SlimSelect({
  select: '#example',
  data: [
    { text: 'A', value: 'a' }
  ],
  format: (item) => {
    return item.toUpperCase(); // ошибка, если item не строка
  }
});

Если callback выбрасывает исключение, оно перехватывается и проксируется в error, предотвращая полное разрушение экземпляра.

Контекст события error

Контекст ошибки важен для диагностики. Обычно он включает:

  • текущий инстанс Slim Select
  • состояние селекта (открыт/закрыт)
  • входные данные операции
  • этап, на котором произошёл сбой

Пример обработчика с анализом контекста:

select.on('error', (err) => {
  if (err.type === 'network') {
    console.log('Проблема сети, повтор запроса...');
  }

  if (err.type === 'parse') {
    console.log('Ошибка структуры данных:', err.context);
  }
});

Повторные попытки и восстановление

Событие error часто используется как точка для реализации retry-механизмов. Slim Select сам по себе не всегда выполняет повторные запросы, поэтому логика восстановления состояния выносится наружу.

Пример стратегии повторного запроса:

select.on('error', (err) => {
  setTimeout(() => {
    reloadData();
  }, 1000);
});

Где reloadData повторно инициирует загрузку данных для селекта.

Граничные случаи

Событие error может не срабатывать в следующих ситуациях:

  • ошибка произошла до инициализации Slim Select
  • исключение перехвачено внешним кодом до библиотеки
  • ошибка находится вне зоны управления (например, глобальный runtime crash)
  • отключена обработка событий в конфигурации

Также важно учитывать, что частые ошибки при загрузке данных могут приводить к лавинообразным вызовам error, поэтому требуется ограничение частоты обработки (debounce/throttle).

Сочетание с другими событиями

error часто взаимодействует с другими событиями жизненного цикла:

  • beforeOpen — ошибка может предотвратить открытие списка
  • afterChange — ошибка при обработке нового значения
  • afterOpen — сбой при рендере списка опций

В сложных интерфейсах обработка error становится центральной точкой контроля стабильности компонента.

Практическая модель обработки

Типовая архитектура обработки ошибок в Slim Select выглядит как слой:

  1. источник данных (API / static)
  2. Slim Select wrapper
  3. событие error
  4. логирование / мониторинг
  5. восстановление состояния UI

В продакшн-среде обработчик часто связывается с системами логирования:

select.on('error', (err) => {
  sendToMonitoring({
    message: err.message,
    type: err.type,
    time: Date.now()
  });
});

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

Оглавление