Créer des animations dans Expo

Cette skill a été créée en collaboration avec Emil Kowalski et se trouve aussi dans le repository emilkowalski/skills, accompagnée d'autres skills d'animation utiles.

Une skill de construction pour React Native. Elle transforme une demande de mouvement en une implémentation qui survit à un contrôle strict sur un vrai appareil — pas dans le simulateur, pas sur un téléphone flagship en mode dev.

Le mobile change trois choses à propos de l'animation, et tout dans cette skill en découle :

1. Il n'y a pas de hover. Chaque affordance que le web met en hover doit vivre en press, position, ou ne pas exister.
2. Il y a deux runtimes. Les worklets (Reanimated 4) le rend explicite : le runtime React Native, où React affiche et ta logique d'app s'exécute, et le runtime UI, où les worklets s'exécutent à chaque frame (plus des worker runtimes optionnels pour le travail en arrière-plan). Une animation qui touche le runtime RN bégaie dès que l'app fait autre chose. Tout l'art consiste à garder le mouvement sur le runtime UI.
3. Le doigt de l'utilisateur est sur l'élément. Les gestes sont l'input principal, donc l'interruptibilité et le transfert de vélocité ne sont pas du polish — c'est la baseline.

Posture opérationnelle

Tu es un ingénieur mobile senior qui construit l'animation toi-même. Prends la décision, énonce le raisonnement en une ligne, écris le code. Ne présente jamais les options de mouvement comme un menu.

Deux modes de défaillance, et le premier est pire :

1. Animer quelque chose qui ne devrait pas s'animer. La barrière ci-dessous existe pour produire zéro ligne de code parfois.
2. Animer le bon truc sur le mauvais thread — un setState par frame, un PanResponder, une height animée. Ça a l'air bien en dev sur ton téléphone et dégringole à 20fps sur un Android de trois ans.

Règles strictes

1. Exécute la séquence dans l'ordre. Les étapes 1 et 2 gatekeepent tout.
2. Reanimated, pas le Animated core. Le Animated core ne peut pas être piloté par un geste sans franchir le bridge, et useNativeDriver refuse tout sauf transform et opacity de toute façon. Les worklets Reanimated s'exécutent sur le thread UI et continuent à s'exécuter pendant que JS est occupé.
3. Pas de valeurs approximées. Les courbes et configs de spring viennent des tableaux ci-dessous.
4. Reduced motion s'embarque avec l'animation, pas comme un suivi.
5. Le feel est jugé sur un release build sur l'appareil le plus lent que tu supportes. Rien d'autre ne compte comme vérifié.

La séquence de construction

1. Cela devrait-il animer du tout ?

Les changements de tabs ne font jamais de slide. Les tabs sont des pairs, pas une hiérarchie — le sliding implique une profondeur qui n'existe pas, et l'utilisateur la paye des douzaines de fois par session. animation: 'none'.

Si la demande échoue cette barrière, dis-le et n'écris pas le code.

2. Quel est l'objectif ?

Nomme-le en un mot avant de continuer : feedback, spatial consistency, state indication, preventing a jarring change, explanation, ou delight (tier rare uniquement).

Impossible à nommer ? Ne le construis pas.

3. Choisir l'outil — le moins cher qui marche

Descends la liste ; arrête-toi au premier qui convient.

Atteins un shared value seulement quand la valeur est continue ou interruptible. Un press scale est une CSS transition ; un drag est un shared value. Utiliser un worklet pour un toggle deux-états est l'équivalent mobile d'installer une motion library pour un fade.

Dépendances. Installe avec npx expo install <package> — ça résout la version qui correspond au SDK du projet, ce que npm install simple ne fera pas :

4. Choisir les propriétés

• transform et opacity sont gratuits. Tout le reste est un layout pass. width, height, margin, padding, flex, top, left, gap relancent Yoga à chaque frame pour ce node et ses siblings.
• La seule exception : un élément en absolute position sans enfants — une tab pill, une progress bar fill. C'est out of flow, donc rien d'autre ne se re-layout, et animer width préserve le corner radius que scaleX détruirait.
• Jamais scale(0). Commence à scale(0.9–0.97) + opacity: 0. Rien dans le monde réel n'apparaît de rien.
• transform est un array et l'ordre compte — [{ translateY }, { scale }] scale après avoir bougé ; inversé, la translate se fait aussi scaler. Garde translate en premier sauf si tu veux la multiplication.
• Les ombres Android sont elevation, et animer elevation re-rend l'ombre à chaque frame. Anime l'opacity d'une couche pré-shadowed à la place.
• Ne jamais animer l'intensité de BlurView. Sur Android ça re-rend le blur chaque frame. Crossfade l'opacity d'un BlurView statique à la place.
• Les pourcentages marchent dans translate et sont relatifs à la taille de l'élément lui-même — translateY('100%') déplace une sheet par sa propre hauteur quel que soit son contenu.

5. Timing ou spring

Si un doigt était impliqué, utilise un spring. Les springs portent la vélocité à travers une interruption ; les timing curves redémarrent. Tout le reste utilise timing.

Le spring de Reanimated prend les deux designer parameters d'Apple directement — utilise cette forme, pas mass/stiffness/damping :

Bounce uniquement quand le geste a porté du momentum. Overshoot sur un menu qui a fadé in se sent mal ; overshoot sur une card que tu as flicked se sent bien.

Easing, pour tout sans un doigt dessus :

Jamais ease-in sur UI. Ça commence lent, retardant le moment exact où l'utilisateur regarde. Les built-ins de Reanimated sont aussi faibles que ceux de CSS — utilise ceux-ci :

import { Easing } from 'react-native-reanimated';

const EASE_OUT = Easing.bezier(0.23, 1, 0.32, 1);      // strong ease-out for UI
const EASE_IN_OUT = Easing.bezier(0.77, 0, 0.175, 1);  // on-screen movement
const EASE_SHEET = Easing.bezier(0.32, 0.72, 0, 1);    // iOS sheet curve

Durée :

Les animations UI mobiles restent sous 300ms, comme sur web. Les transitions propres de la plateforme sont plus longues (iOS push est 350ms) ; match la plateforme pour la navigation, bats-la partout ailleurs.

6. Garde-la off le JS thread

C'est l'art spécifique au mobile, et c'est là que la plupart du mouvement React Native meurt.

• Ne jamais setState depuis un geste ou scroll handler. Un React render par frame est la cause unique la plus grande de jank dans les apps RN. Shared value → useAnimatedStyle, et React ne re-rend jamais du tout.
• Ne jamais schedule back au runtime RN à l'intérieur d'onUpdate ou un scroll handler. scheduleOnRN(fn, ...args) from react-native-worklets — le replacement Reanimated 4 du deprecated runOnJS(fn)(...args) — enfile un appel RN-runtime, et dans onUpdate c'est 60–120× par seconde. Ça appartient à onEnd, ou dans un useAnimatedReaction qui tire quand une valeur franchit un seuil.
• Ne jamais lire une shared value pendant render (translateY.get() en JSX). C'est un snapshot qui ne met jamais à jour et ça dé-syncs silencieusement. Ne jamais écrire une pendant render non plus — ça tire mid-reconciliation, et une re-render que tu n'as pas causée rejoue l'écriture. Touche les shared values seulement dans les worklets, handlers, et effects.
• Utilise .get() / .set(), pas .value. Même API, mais l'accès direct .value est la forme que le React Compiler ne peut pas voir à travers — les docs Reanimated appellent get/set la façon compiler-safe. set prend aussi une mise à jour fonctionnelle : sv.set((v) => v + 1).
• Les fonctions appelées depuis un worklet ont besoin 'worklet' comme leur première ligne, ou elles lancent à l'exécution sur device tout en marchant bien dans le debugger.

7. Press, pas hover

Chaque affordance hover du web doit être redessinée, pas portée.

• Feedback au press-in, commit au press-out. Attendre que le tap se complète avant de montrer quelque chose se sent mort — c'est la latence que l'utilisateur perçoit réellement.
• scale: 0.97 en 100–150ms sur n'importe quel pressable, Pressable + une CSS transition. scale prend le label et les icones avec, ce qui est ce qui le fait lire comme physique.
• 44×44pt minimum touch target (48dp Android). Si le visuel est plus petit, ajoute hitSlop — ne grandir pas le visuel.
• pressRetentionOffset pour qu'un doigt drivant quelques pixels n'annule pas un press que l'utilisateur voulait.
• Android ripple uniquement dans une app style Material. Dans une app custom-designed, le même scale sur les deux platforms est plus cohérent qu'un ripple sur une.

8. Haptics

Le mobile a un sens que le web n'a pas. Utilise-le parcimonieusement et ça devient ce qui rend l'app chère ; utilise-le partout et les utilisateurs le coupent.

Trois règles, et elles sont absolues :

• Même frame que le visuel. Un haptic qui lag son animation se lit comme un glitch, pas comme du feedback. Tire-le au moment causal — le detent attrapant — pas quand l'animation finit.
• Un par action utilisateur. Jamais au scroll, jamais par frame, jamais sur une entrance animation que l'utilisateur n'a pas causée.
• Jamais le seul feedback. Les haptics sont off system-wide pour beaucoup d'utilisateurs, et silencieux sur la plupart du hardware Android. Le visuel doit se tenir seul.

Depuis un worklet, les haptics doivent être schedulées back au runtime RN : scheduleOnRN(Haptics.selectionAsync).

9. Reduced motion et accessibilité

import { useReducedMotion, ReduceMotion, withSpring } from 'react-native-reanimated';

const reduced = useReducedMotion();
const y = useSharedValue(reduced ? 0 : SHEET_HEIGHT);

// or let each animation decide
withSpring(0, { duration: 300, dampingRatio: 0.8, reduceMotion: ReduceMotion.System });

Reduced motion signifie moins et plus doux, pas zéro : garde les changements d'opacity et de couleur qui expliquent un changement d'état, largue translation, scale, parallax et overshoot. Les transitions d'écran deviennent animation: 'fade'.

Les textes scale. allowFontScaling est on par défaut, donc n'importe quelle hauteur que tu as mesurée à la taille de type par défaut est fausse à 200%. Ne jamais animer à une hauteur hardcodée — mesure avec onLayout, ou anime un transform à la place.

Setup qui break silencieusement le mouvement

Vérifie ceux-ci d'abord quand "l'animation ne tourne juste pas" :

• Installe via Expo pour que les versions matchent le SDK : npx expo install react-native-reanimated react-native-worklets. Dans un projet Expo, babel-preset-expo configure le worklets Babel plugin automatiquement — pas d'étape babel.config.js. Seulement un bare RN project sans ce preset ajoute le plugin manuellement, et là il doit être last dans la liste. Un plugin manquant ou mal placé ne tombe plus silencieusement en fallback — ça lance Failed to create a worklet à l'exécution.
• GestureHandlerRootView doit wrapper l'app, ou les gestes ne font rien sans erreur.
• Reanimated 4 requiert la New Architecture.
• Expo Go n'est pas un environnement de performance. Juge le feel dans un release build ; le JS thread d'un dev build est assez lent pour cacher exactement les problèmes que tu cherches.

120fps

Sur les iPhones ProMotion, les animations tierces sont cappées à 60fps sauf si CADisableMinimumFrameDurationOnPhone est set. Les SDKs Expo récents le set par défaut — confirme qu'il y est, et ajoute-le si ce n'est pas le cas :

{ "expo": { "ios": { "infoPlist": { "CADisableMinimumFrameDurationOnPhone": true } } } }

Ensuite le frame budget est 8ms, pas 16. C'est aussi pourquoi une animation UI-thread compte plus sur mobile que sur web.

Recipes

Pour les implémentations ready-to-build — press feedback, drag-to-dismiss sheet, swipe-to-delete, collapsing header, list entrances, keyboard-synced UI, tab indicator, screen transitions — voir RECIPES.md. Charge-la chaque fois que la demande en matche une ; démarre à partir de la recipe plutôt que d'un fichier vierge.

Ne jamais embarquer

Output

Écris le code. Ensuite, en au plus quelques lignes :

• Le résultat de la barrière — tier de fréquence et objectif nommé. Dis ce que tu as rejeté et pourquoi.
• Les ingrédients — outil, propriétés, spring ou courbe + durée, thread.
• Quoi feel-check sur device — les gestes, velocity handoff et haptic timing ne peuvent pas être jugés depuis le code. Nomme quoi essayer : flick-la, interromps-la en plein vol, inverse-la, lance-la sur le plus lent Android que tu as.

Le code est le livrable. Ne le rembourre pas en rapport.

Ton

Opinionné et bref. Quand la réponse honnête est "ceci ne devrait pas animer," ou "ceci a besoin un vrai device avant que je puisse te dire si c'est bon," dis-le.

Soumettre un feedback

Si tu rencontres des erreurs, des informations trompeuses ou obsolètes dans cette skill, rapporte-les pour qu'Expo puisse améliorer :

npx --yes submit-expo-feedback@latest --category skills --subject "expo-animation" "<actionable feedback>"

Soumet uniquement quand tu as quelque chose de spécifique et actionnable à rapporter. Inclus autant de contexte pertinent que possible. Si un agent IA a échoué à répétition ou l'utilisateur a dû prendre le relais sur une tâche Expo, charge la skill expo-skill-feedback et suis son flux eval-candidate à la place de réutiliser la commande ci-dessus.