@n-uf/motion how things move
For desktop-style web apps with windows, panels, docks and toolbars: every change of layout moves the way a good tiling window manager does, and a drag reads what you mean. You give it rects and pointer samples; it moves the real elements.
@n-uf/motion- The frame loop on an injected clock, signals, springs and tweens with the settle, and the gesture recogniser; each also on its own as
./clock,./signals,./values,./gestures. ./layout- Give items rects: the real elements settle there, size changes revealed, never stretched; a held drag (
holdItem), FLIP for DOM groups, reduced motion and batched drawing. ./drag- The drag intent: aiming, priority, hysteresis, the switch hold, room after a delay, a drop that lands where it was shown, and the three previews.
./gestures- Gestures alone: the recogniser, wheel classification, a frame coalescer, and dwell, touch-press and paged-swipe machines.
./browser- The
requestAnimationFrameclock and the reduced-motion query. ./testing- Frame-sampled checks of the motion rules: no overshoot, no jumps, held under the pointer, monotonic, tempo, and content scale.
It doesn't decide where anything goes, and it draws nothing of its own. The core touches no DOM; no framework.
npm i @n-uf/motion README on GitHub (opens in a new tab) Docs