|
|
|
|
|
|
|
|
|
|
|
# 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`](https://api-docs.churros.inpt.fr/pictures/#mutation/setPicture)
|
|
|
|
1. L'API écrit sur le disque dans `/storage/...`
|
|
|
|
2. L'API met à jour `pictureFile` dans la base de données
|
|
|
|
3. La date de modification de la ressource en question étant mise à jour, `pictureURL` change (sauf si le front a mis [`timestamp`](https://api-docs.churros.inpt.fr/users/#type/User:~:text=en%20th%C3%A8me%20sombre-,timestamp,-:%20Boolean%20=) à `false` en demandant le champ sur la ressource)
|
|
|
|
4. 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](https://imgproxy.net/) 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. |
|
|
\ No newline at end of file |
