Устаревшие API

Ранний объектный стиль конфигурации анимаций

В ранних версиях mo.js основной моделью построения анимаций являлось создание отдельных объектов с последующей немедленной инициализацией через метод play() или автоматическим запуском при создании экземпляра.

Ключевая особенность этого подхода — максимальная декларативность внутри одного конструктора:

const tween = new mojs.Tween({
  duration: 1000,
  delay: 0,
  easing: 'linear.none',
  onUpdate(progress) {
    console.log(progress);
  }
});

tween.play();

Устаревание данного стиля связано с тем, что:

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

Позднее этот стиль начал вытесняться системой Timeline, где управление временем стало централизованным.

Устаревший класс Tween как базовая единица анимации

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

Типичный пример:

const tween = new mojs.Tween({
  duration: 800,
  onUpdate(p) {
    element.style.transform = `scale(${p})`;
  }
});

Проблема заключалась в том, что:

  • отсутствовала типизация анимационных свойств
  • логика DOM смешивалась с временной моделью
  • нельзя было переиспользовать анимации как независимые сущности

В современных подходах Tween разделён на более специализированные сущности: shape, burst, timeline.

Устаревший Shape API (до v0.9)

Ранний Shape API представлял собой монолитную конфигурацию, где геометрия, стиль и анимация находились в одном объекте.

const shape = new mojs.Shape({
  shape: 'circle',
  radius: 50,
  fill: 'red',
  stroke: 'black',
  strokeWidth: 4,
  duration: 600
});

shape.play();

Устаревшие особенности:

  • отсутствие модульной структуры shapes
  • невозможность расширения через наследование без глубокого вмешательства
  • ограниченная система кастомных фигур

Позднее API было переработано: появилась концепция Custom Shape, где геометрия отделена от анимационной логики.

Старые параметры управления временем

До внедрения унифицированной временной шкалы использовались разрозненные параметры:

  • delay
  • duration
  • repeat
  • yoyo

Однако их поведение различалось между Tween и Shape, что приводило к несогласованности.

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

new mojs.Shape({
  duration: 500,
  repeat: 3,
  yoyo: true
});

Проблема заключалась в том, что:

  • repeat не синхронизировался внутри Timeline
  • yoyo не поддерживал одинаковую интерполяцию easing
  • задержки применялись локально, а не глобально

Позднее введение Timeline нормализовало эти параметры.

Устаревший Timeline API первого поколения

Первоначальный Timeline был представлен как простой контейнер:

const tl = new mojs.Timeline();

tl.add(tween1, tween2);
tl.play();

Недостатки:

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

Также отсутствовали методы:

  • pause at time
  • seek
  • reverse playback

Эти ограничения делали систему непригодной для сложных сцен.

Устаревшие easing-строки

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

easing: 'quad.out'
easing: 'elastic.out'
easing: 'bounce.in'

Проблема заключалась в:

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

Позднее easing стал объектной системой с унифицированной интерполяцией.

Устаревшая система событий onUpdate / onComplete

Ранее жизненный цикл анимации полностью строился вокруг callback-функций:

onStart()
onUpdate(progress)
onComplete()

Основные ограничения:

  • невозможность подписки/отписки после создания
  • отсутствие событийной шины
  • смешивание логики рендера и бизнес-логики

Типичная проблема:

onUpdate(p) {
  if (p > 0.5) {
    this.stop(); // небезопасное управление внутри цикла
  }
}

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

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

Ранние версии Shape использовали фиксированные параметры трансформации:

  • scale
  • rotate
  • x
  • y
new mojs.Shape({
  scale: { 0: 1 },
  rotate: { 0: 180 }
});

Проблема заключалась в:

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

Современные версии заменили это более гибкой системой трансформаций на основе композиции.

Устаревший Burst API (ранняя реализация)

Ранний Burst представлял собой фиксированную систему разлета элементов:

new mojs.Burst({
  radius: { 0: 100 },
  count: 10
});

Ограничения:

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

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

Устаревшие внутренние зависимости от DOM

В ранней архитектуре многие эффекты напрямую зависели от DOM-элементов:

new mojs.Tween({
  el: document.querySelector('.box'),
  onUpdate(p) {
    el.style.opacity = p;
  }
});

Проблемы:

  • жесткая привязка к браузерному окружению
  • невозможность переиспользования вне DOM
  • отсутствие абстракции рендера

Позднее архитектура была частично абстрагирована для поддержки canvas-ориентированных рендеров.

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

До перехода к современным сборщикам использовался глобальный объект:

const mojs = window.mojs;

Минусы:

  • отсутствие tree-shaking
  • конфликт глобальных пространств имён
  • невозможность ES module оптимизаций

Современные версии поддерживают модульную структуру, но старый глобальный API остаётся в legacy-режиме.

Устаревшие значения по умолчанию

Ранние версии имели неочевидные дефолтные параметры:

  • duration = 0 (в некоторых случаях)
  • easing = linear
  • autoplay = true

Это приводило к поведению, которое сложно было предсказать:

new mojs.Shape({
  shape: 'circle'
});

Без явного duration объект мог мгновенно завершить анимацию.

Устаревшая модель композиции анимаций

До появления развитых Timeline композиция выглядела как цепочка независимых объектов:

tween1.play();
tween2.play();
tween3.play();

Проблемы:

  • отсутствие синхронизации времени старта
  • невозможность группового управления
  • сложность построения сцен

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

Устаревшие ограничения производительности

Ранние версии не имели оптимизаций:

  • отсутствовал batching обновлений
  • каждый tween вызывал отдельный repaint
  • не использовался requestAnimationFrame централизованно

Это приводило к деградации производительности при большом количестве анимаций:

for (let i = 0; i < 100; i++) {
  new mojs.Shape({ radius: i }).play();
}

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

Оглавление