Data Driven Video UI

> L'interface principale pour générer des vidéos via DDV

L'interface embarque une prévisualisation et un formulaire de configuration. La prévisualisation ne peut se lancer tant qu'une première configuration ne lui a été envoyée.
Le formulaire se divise en deux parties :

- une statique qui concerne les paramètres de fichiers (general)
- une dynamique qui se construit en fonction de ce que le template a besoin (specific)

$3

Ils permettent de définir les métadonnées de la vidéo, son tire, ses dimensions, sa fréquence d'images et ses propriétés d'export.

$3

Cette partie est récupérée via l'appel a un fichier de configuration attendu à l'adresse http://url-du-template/config.json. Un template est toujours divisé en deux parties :
- original, les informations indispensables à la version de base (version originale)
- translations, tout ce qui est en plus pour une traduction. C'est un Object dont les clés sont les langues et les sous objets les propriétés

$3

Chaque input du formulaire correspond à un object de configuration appelé model. Il contient à minima :
- type, le type d'input attendu, actuellement sont supportés text, number, select, checkbox, textarea, url et hidden
- name, la clé d'identification de l'input
- label, le label texte associé à l'input et affiché par l'interface
- value, la valeur de l'input à son initialisation. La valeur peut être de type String, Number, Boolean ou Array en fonction de ce qu'on cherche à obtenir

Quelques fois il peut être plus simple pour l'utilisateur final de lui exposer des presets plutôt que l'exhaustivité des réglages. Pour ce faire, des propriétés additionnelles sont à ajouter :

- pour l'input de preset
- separator: la chaine de caratère qui servira de regex pour spliter la valeur du select
- displayDependenciesWhen: une valeur spéciale qui déclenchera l'affichage des inputs cibles. Généralement cette valeur est "custom"
- dependenciesOrder: l'ordre dans lequel le preset est construit. Il servira ensuite à faire correspondre les preset splitté par le séparateur avec les inputs cibles. C'est un tableau de name
- pour l'input cible
- dependsOn: qui est le name du preset auquel il est associé

$3

Le SettingsForm tient à jour un tableau de config. C'est ce tableau qui sera envoyé au DDV Renderer. Voilà un exemple de config :

``
{
general: {
codec: 'ProRes',
exportPresets: 'ProRes — mov',
fileFormat: 'mov',
filename: '2018•09•26_12•33_fr.mov',
fps: 50,
fpsPresets: '50',
host: 'http://10.129.2.156:8081/',
timestamp: 1537958002142,
videoHeight: 1080,
videoPresets: '1920 x 1080',
videoTitle: '',
videoWidth: 1920,
},
specific: {
defaultLocale: 'fr' // The locale used by default for date and number display
locale: null, // if locale is null, then it's the original version, it will override the defaultLocale entry
tweetUrl: 'https://twitter.com/realDonaldTrump/status/1008725438972211200',
traductionContent: null // So the translation items will be null too.
}
}
`

$3

Dans sa preview, l'UI embarque une iframe de l'animation et permet à l'utilisateur de prévisualiser ses paramètres dans un environnement le plus similaire possible. Ce n'est pas parfaitement ISO car l'iframe est rendu dans le navigateur alors que la vidéo sera soumise aux contraintes du codec/format de fichier.

L'UI agit avec le template via l'API window.postMessage car l'objet window est non disponible au parent hébergeant l'iframe (la preview dans notre cas).

Il est donc indispensable que le template dispose du listener adequat. En l'occurence l'UI envoie au template les données attendues via l'évenement
`
{ type: 'init-template-data', templateData: {...config.specific, fps: config.general.fps} }
`

L'UI écoute quand à elle quelques évenements que le template lui envoie :

- { type: 'animation-update', value: something } qui met à jour la barre de progression
- { type: 'duration-update', value: something } qui permet de savoir le temps total de l'animation
- { type: 'default-filename', value: something } qui permet d'autogénérer un nom de fichier




$3


C'est très simple, il suffit de suivre les étapes suivantes :
1. augmenter la version du package via npm version patch|minor|major
2. publier via npm publish
3. _optionnel mais ne pas oublier de pousser sur le repo_
3. dans le projet toolkit-ui, modifier le package.json pour être à la version correspondante
4. pousser la modification de toolkit-ui sur la branche dev
5. les runners gitlab s'occupent du reste 🚀

$3

Pour éviter le risque que deux fichiers aient un nom identique (problématique pour Renderer et AWS S3), chaque fichier possède un id aléatoire généré d'une longueur de 6 caractères sur cet alphabet

` bash
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz-
`

Ce qui réduit grandement le risque de collision, déjà faible, du nom des fichiers.
Sachant que cet id ne sera qu'une petite partie du nom du fichier, et que les fichiers de plus de 15 jours sont automatiquement supprimés.

Exemple d'un nouveau nom de fichier :

`bash
20191219_152018_twitter_vo_um0p7w.mxf
`


Voir : https://zelark.github.io/nano-id-cc/




$3

` bash


install dependencies

npm install

serve with hot reload

npm run serve

build for production with minification

npm run build
``