Floating Toolbar looks like a simple contextual bar, but it's built from one spring config reused three times: once for the whole shell mounting in, once for the shell leaving, and once per action button, per interaction. The component itself is small; the feel comes from reusing that one number set everywhere.

actions is a flat array, the same approach as Context Menu: plain objects the toolbar maps over instead of compound components. Structurally, an "active" action is identical to an idle one; only aria-pressed and two class names differ.

Every button, and the shell around them, carries layout. Add or remove an action and Framer measures the before/after boxes and animates the diff, so the row never jump-cuts when its contents change.

AnimatePresence mounts and unmounts the whole motion.div, and the enter springs opacity, y and scale on a stiff, barely-overshooting spring.

520/32 is a much stiffer, more critically damped pair than the tooltip's 170/12/0.1. The toolbar should feel immediate, as if it was always there and just became visible. The exit target doesn't mirror the enter (y: 8, not 12; scale: 0.95, not 0.92): it travels a shorter distance on the way out, because a lingering overshoot on dismissal would read as sluggish.

The same 520/32 spring drives every action's hover and press state, independent of the shell.

whileHover/whileTap are declarative targets rather than event handlers you wire up yourself. Framer owns the pointer listeners and animates toward whichever state is currently true. Because it's the same spring as the shell's entrance, a button lifting under the cursor moves like part of the toolbar it floats in instead of a separate hover effect layered on top.

Two springs, one number set: stiffness: 520, damping: 32 moves the whole shell in and out, and lifts and settles each button under the pointer.