Photos

Churros permet de mettre une photo de profil pour pas mal de ressources différentes.

Il a émergé de ça le besoin d'avoir une gestion centralisée des photos de profils pour pas réécrire du code 50 fois.

Processus

Quand on change une photo de profil:

1. Le front appelle Mutation.setPicture
2. L'API écrit sur le disque dans /storage/...
3. L'API met à jour pictureFile dans la base de données
4. La date de modification de la ressource en question étant mise à jour, pictureURL change (sauf si le front a mis timestamp à false en demandant le champ sur la ressource)
5. Tout le monde reçoit immédiatement (à un chargement de page près), la nouvelle photo

Détails

Mutation.setPicture

La mutation prend notamment en argument un paramètre de type File. Grâce à Houdini, pas besoin de connaître les détails sur les requêtes de type multipart/form-data, il suffit de passer comme valeur à la variable une instance File javascript.

De toutes façons, l'appel de cette mutation doit être fait (sauf si le bon sens contre-indique) dans FormPicture.svelte: le composant s'occupe de l'affichage et de la gestion de la suppression/modification de la photo en fonction du type de ressource.

Si on implémente une nouvelle ressource avec photo de profil, il faut rajouter un cas dans ce composant.

Écriture sur disque

Le fichier lib/picture.ts dans l'API abstrait le calcul des chemins pour écrire sur disque.

En gros, les fichiers sont stockés dans racine du stockage / type de ressource / identifiant.png

Sachant que la racine du stockage est contrôllable par la variable d'environnement STORAGE (cf .env.example pour la doc)

Écriture en base de données

La base de données stocke le chemin vers l'image sur une colonne pictureFile de la ressource associée. Le chemin est relatif à la racine du stockage.

Au cas où l'on se mette à stocker les images en .webp, à changer l'aborescence, ou quoi que ce soit, les anciennes images ont pas besoin d'être bougées et continue de marcher, et même ça permet d'être sûr de où est l'image sans faire d'hypothèses.

Exposition de l'URL complète à l'API

Avant, on demandait à l'API pictureFile directement et le front effectuait le calcul de l'URL effective. Mais maintenant, l'API expose pictureURL (et pictureFile est déprécié).

Cela a plusieurs avantages:

• Moins de calculs réberbatifs à faire sur le front
• Si d'autres clients ont besoin de photos de profil, ils n'ont pas à faire d'hypothèses sur des détails d'implémentation de Churros même
• On peut décider de changer les URLs (en passant par exemple par imgproxy pour les compresser on the fly, ou rajouter de l'authentification en embeddant un token dans l'URL, etc...) sans avoir à toucher aux fronts (pluriel parce que potentiellement d'autres clients)

Mais ça a un désavantage plutôt minime

• On ne peut pas instantanéement changer en mode image sombre: les logos des groupes (et potentiellement plus des ressources dans le futur) permettent d'indiquer une variante pour thème sombre. Pour obtenir l'URL de la variante, ont doit demander le champ pictureURL(dark: true). Le workaround est tout simplement de demander les deux URLs, et de switcher entre les deux quand le thème change.