Deprecation notices

Понятие устаревших возможностей и политика изменений

В библиотеке Pikaday устаревшие (deprecated) возможности появляются в результате эволюции API, изменения подходов к работе с датами и упрощения внутренней архитектуры. Устаревание не означает мгновенное удаление функциональности: чаще всего оно вводится как предупреждение о том, что конкретный способ использования больше не рекомендуется и может быть удалён в будущих версиях.

Основная цель депрекейтов в Pikaday заключается в снижении зависимости от сторонних библиотек, уменьшении неоднозначного поведения и унификации обработки дат через нативный JavaScript Date.

Ключевые характеристики устаревших API в Pikaday:

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

Устаревание Moment.js как внешней зависимости

Одним из наиболее значимых изменений в экосистеме Pikaday стало постепенное смещение от тесной интеграции с Moment.js.

Роль Moment.js в ранних версиях

Ранее Moment.js часто использовался как вспомогательная библиотека для:

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

Pikaday мог принимать moment-объекты или использовать Moment.js внутри пользовательских коллбеков.

Причины отказа

Использование Moment.js стало считаться нежелательным по нескольким причинам:

  • увеличение размера бандла;
  • неизменяемая (mutability-heavy) модель работы с датами;
  • прекращение активного развития Moment.js;
  • появление более современных альтернатив (date-fns, Luxon, native Temporal API).

Последствия для API Pikaday

Устаревшими стали сценарии, в которых:

  • передача moment-объектов в setDate или getDate считалась допустимой по умолчанию;
  • ожидалось автоматическое форматирование через Moment;
  • внутренние методы предполагали наличие глобального moment.

Современная модель предполагает использование только нативного Date, а все преобразования выполняются вне Pikaday.

Депрекейт форматирования и парсинга через встроенные механизмы

Устаревание автоматического парсинга строк

Ранее Pikaday мог принимать строки даты и пытаться интерпретировать их с помощью внутренних правил или сторонних библиотек.

Устаревшие сценарии:

  • передача строк в setDate('2020-01-01') с ожиданием универсального парсинга;
  • автоматическое определение формата строки;
  • неявное использование локали при разборе даты.

Современный подход:

  • Pikaday принимает только Date-объекты;
  • строковый парсинг выносится в пользовательский код;
  • форматирование выполняется через toString(date) callback.

Устаревание опции format как универсального механизма

Опция format ранее использовалась как единая точка управления отображением и парсингом даты.

Deprecated-поведение:

  • формат одновременно определял вывод и ввод;
  • ожидалось обратимое преобразование строка ⇄ Date внутри библиотеки.

Современное поведение:

  • format используется только для отображения;
  • обратное преобразование не гарантируется;
  • ответственность за парсинг полностью внешняя.

Устаревание связки toString / parse в старом виде

Ранее используемая модель

Pikaday предоставлял функции:

  • toString(date, format)
  • parse(dateString, format)

которые часто рассматривались как симметричная пара.

Проблема симметрии

В реальных сценариях симметрия нарушалась:

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

Депрекейт подхода

Устаревшей считается идея, что Pikaday должен гарантировать:

  • полный цикл преобразования строки в дату и обратно;
  • одинаковую интерпретацию формата в обе стороны.

Текущая модель

  • toString остаётся как UI-слой;
  • parse полностью выносится наружу;
  • Pikaday не участвует в интерпретации строк.

Устаревание некоторых коллбеков и изменение их роли

onSelect и его эволюция

Коллбек onSelect остаётся, но устаревшими считаются паттерны его использования:

  • изменение DOM внутри onSelect как основная логика приложения;
  • зависимость от внутреннего состояния Pikaday;
  • использование onSelect как единственного источника правды о состоянии даты.

Современный подход:

  • onSelect рассматривается как событие уведомления;
  • состояние хранится вне компонента;
  • обновления UI происходят реактивно.

Устаревание onOpen, onClose как бизнес-логики

Ранее эти события часто использовались для:

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

Депрекейт-паттерн:

  • привязка бизнес-логики к UI-событиям календаря.

Современный подход:

  • onOpen и onClose используются только для UI-эффектов;
  • логика приложения отделяется в отдельные слои.

Устаревшие параметры конфигурации

container и ручное управление DOM

Ранее container активно использовался для:

  • внедрения календаря в произвольный DOM-узел;
  • динамического перемещения календаря.

Deprecated-подход:

  • манипуляция DOM-контейнером после инициализации;
  • перенос календаря между контейнерами без пересоздания экземпляра.

Современная модель:

  • календарь привязывается к одному контейнеру;
  • перенос осуществляется через пересоздание экземпляра;
  • DOM-манипуляции минимизируются.

bound как источник неочевидного поведения

Опция bound ранее влияла на:

  • автоматическое открытие по фокусу;
  • привязку к input-элементу.

Устаревшие сценарии:

  • динамическое переключение bound после инициализации;
  • ожидание мгновенного перепривязывания событий.

Современное поведение:

  • bound считается фиксированным при создании;
  • изменение требует пересоздания календаря.

keyboardInput и деградация управления вводом

Ранее существовали сценарии, где:

  • ввод даты вручную полностью контролировался Pikaday;
  • библиотека пыталась валидировать строку в input.

Депрекейт-подход:

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

Современная практика:

  • ввод обрабатывается отдельно;
  • Pikaday отвечает только за выбор через UI.

Устаревание внутренних механизмов локализации

Старый подход к i18n

Pikaday ранее поддерживал локализацию через:

  • объект i18n с фиксированными ключами;
  • встроенные массивы месяцев и дней недели;
  • ожидание полной структуры перевода.

Deprecated-поведение

  • частичное переопределение i18n (например, только месяцев);
  • зависимость от внутреннего формата ключей;
  • отсутствие гибкости при расширении локалей.

Современные требования

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

Устаревание синхронной модели обновления состояния

Ранее распространённый подход

Pikaday часто использовался как:

  • синхронный источник состояния выбранной даты;
  • компонент, напрямую изменяющий DOM input.

Deprecated-паттерны:

  • чтение значения через DOM после каждого изменения;
  • ожидание мгновенного обновления внешних данных.

Современная модель

  • Pikaday рассматривается как контролируемый компонент;
  • состояние даты хранится вне библиотеки;
  • обновления происходят через явные вызовы setDate.

Устаревшие паттерны работы с несколькими экземплярами

Проблемы старого подхода

Ранее допускались сценарии:

  • один input — несколько экземпляров Pikaday;
  • переиспользование одного экземпляра между полями;
  • динамическое переключение field.

Deprecated-поведение:

  • отсутствие чёткой привязки жизненного цикла;
  • утечки событий;
  • неконсистентное состояние календаря.

Современный подход

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

Устаревание прямого доступа к внутренним свойствам

Ранее используемые внутренние поля

Разработчики часто обращались к:

  • _o (internal options object);
  • _d (current date);
  • _c (calendar state);
  • DOM-узлам внутри экземпляра.

Deprecated-поведение

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

Современные ограничения

  • внутренние поля считаются приватными;

  • любое использование вне API рассматривается как нестабильное;

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

    • setDate
    • getDate
    • show
    • hide
    • destroy

Устаревание модели “самостоятельного рендера”

Старый подход

Pikaday ранее позволял:

  • частично вмешиваться в процесс рендеринга;
  • модифицировать DOM после отрисовки без перерисовки;
  • использовать нестабильные hooks для изменения UI.

Deprecated-подход

  • ручное изменение DOM календаря;
  • зависимость от внутренней структуры HTML.

Современный подход

  • рендеринг считается полностью управляемым библиотекой;
  • любые кастомизации выполняются через CSS и ограниченные callbacks;
  • DOM структура рассматривается как implementation detail.

Устаревание смешанных моделей управления датой

Проблема гибридного контроля

Ранее Pikaday позволял одновременно:

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

Deprecated-поведение:

  • рассинхронизация состояния;
  • конфликт источников истины;
  • неявные обновления UI.

Современная модель

  • единый источник истины вне Pikaday;
  • явная синхронизация через API;
  • исключение автоматических преобразований.

Итоговые направления изменений API (без формального завершения)

Эволюция устареваний в Pikaday демонстрирует последовательное движение к:

  • уменьшению скрытой логики;
  • отказу от внешних зависимостей;
  • переходу к нативному Date;
  • разделению UI и бизнес-логики;
  • устранению неявных преобразований данных;
  • стабилизации публичного API при одновременной заморозке внутренней реализации.
Оглавление