iamryoman/remotion-meilleures-pratiques

Meilleures pratiques Remotion

Construire la sortie Remotion comme une fonction déterministe de l'image, des props d'entrée et des ressources déclarées. Préservez les modifications de l'utilisateur ainsi que le gestionnaire de paquets, l'architecture et le style existants du projet, sauf si la tâche nécessite un changement.

Commencer par des preuves

1. Lisez les instructions du dépôt et inspectez package.json, le fichier de verrouillage, la configuration Remotion, le point d'entrée, les compositions enregistrées et les tests voisins.
2. Sur un projet existant, exécutez node <skill-directory>/scripts/audit-remotion-project.mjs <project-root>. Considérez sa sortie comme une preuve, pas une autorisation de mise à niveau.
3. Enregistrez la version installée de Remotion avant de choisir les API. Maintenez tous les paquets remotion et @remotion/* exactement sur la même version. N'ajoutez pas de second fichier de verrouillage.
4. Identifiez si le livrable est une vidéo, une image fixe unique, une image échantillonnée d'une vidéo, ou un lot de captures d'écran de store.
5. Définissez l'ID de composition, les dimensions, les FPS, la durée, les props, le chemin de sortie et les ressources requises avant l'implémentation.

Charger uniquement la référence pertinente

• Pour <Composition>, <Still>, useCurrentFrame(), interpolate(), spring(), <Sequence> ou <Series>, lisez composition-and-timing.md.
• Pour staticFile(), les médias, les polices, les données réseau, useDelayRender(), delayRender() ou calculateMetadata(), lisez assets-and-async.md.
• Pour la CLI, renderStill(), le rendu côté serveur, ou Remotion Lambda, lisez rendering-and-lambda.md.
• Pour les rendus lents, l'utilisation élevée de la mémoire, le non-déterminisme, ou la stratégie de vérification, lisez performance-and-testing.md.
• Pour les images de l'App Store ou Google Play, y compris la sortie 1284×2778 déléguée par screenshot-studio, lisez store-stills.md.
• Lorsqu'une règle d'API ou de plateforme a pu changer, consultez la source primaire en direct liée dans sources.md avant de coder.

Règles d'implémentation non négociables

• Dérivez le temps de useCurrentFrame() et useVideoConfig(). N'utilisez pas de transitions CSS, d'animations CSS par images clés, de temporisateurs basés sur l'horloge système, ou de hasard non ensemencé pour le mouvement rendu.
• Limitez les animations finies à moins que l'extrapolation ne soit intentionnelle. Exprimez les temporisations en secondes multipliées par fps lorsqu'elles représentent le temps, et centralisez les durées de scènes partagées.
• Souvenez-vous que useCurrentFrame() est relatif à l'intérieur d'un composant temporisé. Passez une image absolue depuis la racine de la composition uniquement lorsque la synchronisation globale est intentionnelle.
• Utilisez <Sequence> pour un placement explicite sur la timeline parente et <Series> pour des scènes contiguës. Donnez à chaque scène une durée explicite.
• Placez les ressources locales dans public/ et résolvez-les avec staticFile(). Utilisez les composants médias Remotion plutôt que des balises HTML brutes pour que le rendu attende correctement les médias.
• Préférez useDelayRender() à l'intérieur des composants. Créez un handle une fois, effacez-le exactement une fois, et appelez cancelRender(error) en cas d'échec. Préférez calculateMetadata() pour les données nécessaires à la détermination des props ou des métadonnées une fois par rendu.
• Gardez le code de temps de rendu exempt d'hypothèses de navigateur qui ne sont pas disponibles dans Chromium sans tête ou Lambda. N'exposez jamais les identifiants AWS ou autres secrets au bundle du navigateur.
• Validez les dimensions, le format de fichier, la politique du canal alpha et les règles spécifiques à la plateforme indépendamment pour chaque cible de store. Ne supposez jamais qu'une taille de portrait est acceptée à la fois par Apple et Google.

Travailler dans une boucle de rendu serrée

1. Vérifiez les types et exécutez les tests ciblés.
2. Rendez des images fixes représentatives : le début, chaque limite de scène, un point médian de mouvement, et la dernière image.
3. Inspectez les pixels réels, pas seulement l'aperçu Studio. Vérifiez le recadrage, le retour à la ligne du texte, les marges de sécurité, les ressources manquantes et les arrière-plans transparents.
4. Rendez une courte plage d'images ou une ébauche en basse résolution avant un rendu vidéo complet et coûteux.
5. Évaluez la concurrence sur la machine de déploiement plutôt que de la maximiser aveuglément.
6. Rendez l'artefact final avec un ID de composition, des props, un chemin de sortie, des dimensions et un format explicites.
7. Vérifiez le statut de sortie, l'existence du fichier, les dimensions en pixels, la durée/le nombre d'images le cas échéant, et un échantillon visuel final.

Faire des changements de manière conservatrice

• Ne mettez pas à niveau Remotion, ne réécrivez pas la structure du projet et ne remplacez pas les composants médias sauf si la tâche l'exige ou si l'utilisateur l'approuve.
• Limitez les API plus récentes à la version installée ; fournissez une solution de repli compatible lorsque c'est pratique.
• Ne cachez pas les échecs de rendu avec des augmentations arbitraires du délai d'attente. Identifiez d'abord le handle non résolu, la requête réseau, la ressource, la police ou le décodage multimédia.
• Ne revendiquez pas une amélioration des performances sans mesures issues de rendus comparables.