Система выполнения анимаций в Velocity.js основана на строгой последовательности задач, где каждая операция добавляется в очередь конкретного элемента и исполняется только после завершения предыдущей. Это позволяет строить сложные анимационные сценарии без необходимости вручную синхронизировать тайминги и состояния.
Каждый DOM-элемент в Velocity.js получает собственную независимую очередь анимаций. Это означает, что два элемента, даже при одинаковых вызовах, не разделяют общий список задач. Такой подход исключает гонки состояний и упрощает предсказуемость поведения интерфейса.
Очередь представляет собой структуру FIFO (first in, first out), где каждая новая анимация помещается в конец списка и ожидает завершения предыдущей операции. При этом сама анимация может быть как одиночной трансформацией, так и сложным набором свойств CSS, изменяемых одновременно.
Ключевой принцип: выполнение всегда линейно внутри одного элемента, но параллельно между разными элементами.
При каждом вызове Velocity для элемента создаётся или дополняется очередь. Например, последовательные вызовы:
не исполняются мгновенно. Вместо этого формируется последовательный список задач, каждая из которых получает управление только после завершения предыдущей.
Такой механизм позволяет строить композиции без ручного управления таймерами или колбэками.
Каждая анимация внутри Velocity.js превращается в задачу, содержащую:
Эта задача помещается в очередь элемента и ожидает своего цикла выполнения. Исполнитель очереди активируется автоматически при добавлении первой задачи или после завершения текущей анимации.
Если очередь уже выполняется, новые задачи просто добавляются в конец без прерывания текущего состояния.
Одним из ключевых архитектурных решений является полная независимость очередей разных DOM-элементов. Это означает:
Таким образом, система очередей в Velocity.js фактически создаёт многопоточную модель поведения на уровне UI, хотя выполнение остаётся однопоточным в рамках JavaScript.
Порядок выполнения можно контролировать через добавление задач в начало или конец очереди. Это позволяет внедрять приоритетные анимации, которые должны выполниться раньше стандартного потока.
В типичном сценарии:
Такой подход часто используется для реактивных интерфейсов, где необходимо мгновенно отреагировать на пользовательское действие, прерывая менее важные переходы.
Каждая анимация сигнализирует о своём завершении автоматически, что служит триггером для запуска следующей задачи в очереди. Завершение определяется не таймером, а фактическим окончанием всех вычисляемых изменений.
Это особенно важно при работе с:
Система не переходит к следующей задаче до тех пор, пока текущая не подтвердит завершение всех переходов.
Параметр queue управляет тем, попадёт ли анимация в стандартную очередь или будет выполнена отдельно от неё.
При значении queue: false:
Это создаёт эффект «вырванного из очереди» действия, полезного для микровзаимодействий и мгновенных откликов интерфейса.
Очередь считается активной, пока выполняется хотя бы одна задача. В этот момент любые новые анимации автоматически ставятся в ожидание.
После завершения последней задачи очередь разблокируется и может либо завершить своё существование, либо ожидать новых задач в зависимости от контекста вызовов.
Важным аспектом является отсутствие необходимости вручную очищать очередь в стандартных сценариях: система сама завершает цикл при отсутствии задач.
Система очередей допускает принудительное прерывание текущего потока. При этом возможны два режима:
В первом случае последующие задачи сохраняются и могут быть продолжены. Во втором — очередь полностью сбрасывается, и элемент возвращается в исходное состояние исполнения.
Каждая анимация возвращает структуру, совместимую с цепочками исполнения. Это позволяет выстраивать последовательности, где завершение одной задачи логически связано с запуском следующей.
Такой подход создаёт мост между:
В результате управление становится более гибким, особенно в сложных сценариях интерфейсных переходов.
Хотя очередь оперирует задачами последовательно, каждая задача может содержать несколько свойств, изменяемых одновременно. Это означает, что внутри одного шага очереди выполняется параллельное изменение CSS-параметров.
Таким образом структура имеет два уровня:
Это разделение обеспечивает баланс между контролем порядка и производительностью.
При работе с набором элементов каждая сущность имеет собственную очередь, однако вызовы Velocity часто применяются массово. В этом случае создаётся синхронизированный набор очередей, где каждый элемент получает идентичный набор задач, но исполняет их независимо.
Это позволяет строить:
Задержки не блокируют очередь как отдельное состояние. Вместо этого они становятся частью задачи, увеличивая её длительность. Это важно, поскольку очередь продолжает оставаться линейной, без введения дополнительных состояний ожидания.
Такая модель исключает необходимость внешних таймеров и делает поведение предсказуемым даже при сложных композициях анимаций.
Если новая анимация вызывается до завершения текущей, она не прерывает исполнение, а добавляется в конец очереди. Это создаёт эффект накопления сценария, где пользовательские действия формируют цепочку будущих изменений.
При этом возможно управление приоритетами, позволяющее вставлять задачи в начало, если требуется мгновенная реакция интерфейса.
Главная особенность системы заключается в том, что порядок исполнения всегда заранее определён. Независимо от асинхронности среды, каждая задача получает строгое место в последовательности.
Это делает поведение интерфейса воспроизводимым и упрощает отладку сложных анимационных сценариев, где важно точное соблюдение последовательности изменений.