@react-gnome/tamagui

Tamagui animation driver bound to @react-gnome/animation. Drop-in alternative to @tamagui/animations-react-native, designed for apps running Tamagui under the React Gnome renderer.

Usage

// tamagui.config.ts
import { createTamagui } from "@tamagui/core";
import { createAnimations } from "@react-gnome/tamagui";

export default createTamagui({
  animations: createAnimations({
    bouncy: { type: "spring", stiffness: 200, damping: 18 },
    lazy:   { type: "timing", duration: 400 },
    quick:  { type: "timing", duration: 150 },
  }),
  // ... rest of config
});

The driver implements the same protocol shape Tamagui's stock RN driver does — isReactNative, supportsCSSVars, useAnimations — so swapping is purely a config-line change.

Why this exists

Tamagui's stock @tamagui/animations-react-native driver imports Animated from react-native-web. Under React Gnome we alias react-native-web → @react-gnome/react-native, which would normally land the driver on our Animated namespace. But @tamagui/core/native (the build users get via the @tamagui/core → @tamagui/core/native resolution) bundles its own self-contained copy of Animated internally. Tamagui's styled-component pipeline routes animated components through that internal copy, not through whatever the external driver exposes.

This driver sidesteps that by owning the tick loop inside the useAnimations hook itself: every numeric style key gets a wrapped AnimatedValue, timing/spring drives it from @react-gnome/animation, and a forceUpdate on each tick re-renders the Tamagui component with the current snapshot. Tamagui's component layer sees plain numbers per frame and renders normally through our reconciler.

How we get past Tamagui v2's animation gate

Tamagui v2 only invokes the driver's useAnimations hook when the component reaches its shouldUseAnimation gate:

hasAnimationProp = !isHOC && "transition" in props || hasAnimatedStyleValue(props.style)
willBeAnimated  = hasAnimationProp && useAnimations && !isHOC
shouldUseAnimation = willBeAnimated && useAnimations && !isHOC

The runtime animation="..." prop alone does NOT pass this gate — Tamagui expects the prop to be translated to a transition prop (or one of the pseudo-state transitions: hoverStyle/pressStyle/focusStyle) at compile time by @tamagui/babel-plugin (Metro/native) or @tamagui/vite-plugin (Vite/web). Neither targets a GJS host, so without intervention the prop stays inert and the driver hook never fires.

The @multiplatform.one/vite-plugin-gnome package's tamaguiPlugin adds a single regex transform that rewrites the gate assignment so "animation" in props ALSO opens the gate:

// before:
hasAnimationProp = Boolean(!isHOC && "transition" in props || ...);
// after:
hasAnimationProp = Boolean(!isHOC && ("transition" in props || "animation" in props) || ...);

With that, <TamaguiView animation="bouncy"> springs as expected — Tamagui calls our useAnimations on every component-state change, the driver drives per-key AnimatedValues toward the new target via spring/timing from @react-gnome/animation, and a forceUpdate per tick re-renders the component with the interpolated style snapshot.

The transform lives next to the other bundle patches in @multiplatform.one/vite-plugin-gnome. Any vite config that consumes the shared tamaguiPlugin gets it automatically (visual / smoketest / main app).

<Animated.View> from @react-gnome/react-native is still a valid path when you want imperative widget-mutation without React re-renders per tick — it's strictly cheaper for very-large animated subtrees. For typical component animations, the Tamagui animation prop now works:

const [active, setActive] = useState(false);
return (
  <TamaguiView
    animation="bouncy"
    width={active ? 180 : 100}
    backgroundColor={active ? "#3584e4" : "#e01b24"}
    onPress={() => setActive((v) => !v)}
  />
);

See also

• @react-gnome/animation — the primitives this driver wraps
• @react-gnome/react-native — Animated.View direct path