Maj Nuxt v4

[hellochloe1989]

Passage de Nuxt v3 à Nuxt v4, et mise à jour des dépendances

Les 3 changements principaux sont :

• Les sources de l'appli frontend ont été déplacées dans un sous-dossier frontend/app , conformément à la documentation nuxt. Cela inclut le fichier généré des types openapi, qui passe de frontend/lib/api.d.ts à frontend/app/lib/api.d.ts
• La validation typescript inclut désormais noUncheckedIndexedAccess, qui considère que sans vérification préalable, accéder à un index de tableau ou une clé d'objet renvoie potentiellement undefined
• Le serveur de dev nuxt est moins lenient sur les entêtes envoyées lors des requêtes, il a fallu légèrement changer la configuration du reverse-proxy de dev pour que les entêtes soient correctes dans chaque situation, notamment l'entête Connection: Upgrade pour les websockets contre Connection: Close pour les fichiers (auparavant il était possible de toujours passer Connection: Upgrade)

Côté dépendances, il y a notamment une mise à jour de PrimeVue de v4.3 à v4.4 (page des releases), et une mise à jour de vue3-openlayers de v11 à v12 (notes de migration).

Il n'y a pas de changement de fonctionnalité notable introduit. Les modifications du code sont là essentiellement pour résoudre les erreurs typescript dues à noUncheckedIndexedAccess, en général associées à des situations où il n'est pas possible que l'accès au tableau ou objet renvoie undefined.

Pour tester, étant donné qu'il s'agit d'une mise à jour globale, je recommande de tester autant de parties de l'application que possible, à la fois en frontend public et frontend admin.

[hellochloe1989]

La mise à jour primevue a révélé un soucis qui était caché avant au niveau des champs de date (évènements et input date). Auparavant les DatePicker ne rencontraient pas de soucis, qu'on leur fournisse une donnée string ou Date, mais à présent avec la configuration par défaut actuelle ils attendent vraiment des objets Date.

La signature typescript indique que en théorie la donnée manipulée dans les champs entités / commentaires est de type Date. Cependant, actuellement on ne traite pas du tout les retours backend, et la donnée est au format string utilisé pour le transfert json. Cela casse l'affichage des pages d'édition de champs contenant des dates, par exemple l'édition d'un commentaire existant en admin, si ce dernier contient des évènements.

Retour en draft le temps de corriger.

[hellochloe1989]

Le dernier commit ajoute un processing aux entités et commentaires après leur chargement du backend pour mettre au bon format les champs data: unknown. Cela inclut le remplacement des dates au format string par des objets Date, ca résoud le soucis précédemment indiqué.

Il n'est malheureusement pas possible de mettre ce processing dans le clients API de l'admin une bonne fois pour toutes, car on effectue à différentes occasions des JSON.stringify() qui rendent caduque le processing fait en amont.

De plus, il est nécessaire de connaitre le format des champs pour se faire, et il n'est pas nécessairement connu lors d'un appel à getEntity(entity_id) par exemple, car il est stocké au niveau de la famille de l'entité.

Je recommande de tester qu'il est bien possible d'ajouter et de modifier des entités avec tous les types de champs possibles suite à ce commit.

[hellochloe1989]

J'ai modifié le dernier commit pour que la mise en forme des champs des entités et des commentaires soit plus "fire and forget" dans le code. Concrètement :

• Le module field-utils.ts apporte les fonctions de mise en forme / coercion au bon format des champs. Cette mise en forme se veut avec aussi peu de perte que possible, c'est à dire que si la coercion ne peut pas se faire (incohérence ingérable entre ce que renvoie le backend et l'attendu), alors les données du backend priment, quitte à faire planter l'applicatif, mais avec aucun risque de perte de donnée.
• Les clients API du viewer et de l'admin appellent eux mêmes les fonctions de mise en forme des champs, ce n'est plus la responsabilité des appelants (fire and forget, yeah !)
• Il est parfois nécessaire de passer en paramètre les définitions des champs aux clients API quand ces informations ne sont pas disponibles dans les objets manipulés. Par exemple getEntity(id: string, entityFields?: FormField[]) dans le client admin. En l'absence des définitions, aucune mise en forme n'a lieu.
• Les appels JSON.parse(JSON.stringify())) qui faisaient perdre le formatage des champs des entités et des commentaires ont été remplacés par des appels à structuredClone().

Je recommande de tester qu'il est bien possible d'ajouter et de modifier des entités et des commentaires avec tous les types de champs possibles suite à ce commit.

[chitochi]

J’ai essayé de tout casser, mais tout semble bien fonctionner !

[hellochloe1989]

J'ai retesté les features des PR fusionnées récemment, elles sont toujours ok après le rebase.

[chitochi]

J’ai retesté plein de trucs et je pense que c’est OK !