[META] Réorganisation du code pour les vacances et plus
Ceci est une méta-issue, pour expliquer pleins de trucs, mais doit juste faire ref. à d'autres issues
Réorganisations pour les vacances
Utiliser des object fields au lieu d'avoir pleins de queries à la racine
par exemple:
query {
groups(type: Club) {
name
members(search: "Example") { uid, fullName }
}
}
Au lieu de devoir se taper un champ groupUid
pour limiter le résultat de genre searchGroupMembers
!103 (merged))
Splitter le code (Dans src/, au lieu d'avoir objects/ et services/, on a un dossier par module, et dans chaque module:
-
types/<type name>.ts
pour les types graphql et les schémas zod pour les input types (cf Des schémas zod pour une validation symmétrique plus bas) -
permissions/<type name>.ts
pour des fonctions de la formeuserCan<action><type>
à utiliser dans les authScopes (cf Les fonctions de l'API pour afficher/cacher symmétriquement plus bas) -
resolvers/queries.<type name>.ts
pour les queries -
resolvers/mutations.<type name>.ts
pour les mutations -
resolvers/<type name>.<field name>.ts
pour les fields sur les types qui ont des gros resolvers -
utils/<whatever>.ts
pour les fonctions utilitaires (possibilité d'avoir un fichierutils.ts
à la place quand c'est pas trop gros?) -
index.ts
qui rééxporte tout (possibilité d'auto-générer ce fichier, cf https://github.com/bencoveney/barrelsby)
Ça donnerait un truc comme ça pour ce qu'on a actuellement, par exemple les évènements:
src/
events/
index.ts
types/
event.ts # Event, EventInput (et son schéma zod)
tickets.ts # Ticket, TicketInput (et son schéma zod), TicketGroup, TicketGroupInput (et son schéma zod)
bookings.ts
permissions/
event.ts # contient genre userCanManageEvent, userCanSeeEvent
tickets.ts # userCanSeeTicket
bookings.ts # userCanSeeBooking
resolvers/
queries.event.ts
queries.tickets.ts
queries.bookings.ts
mutations.event.ts
mutations.tickets.ts
mutations.bookings.ts
mutations.bookings.book.ts # la mutation pour réserver un billet est giga grande
utils/
recurrence.ts # fonctions pour gérer les dates des évènements récurrents
Et en ce qui concerne le reste, genre index.ts, builder.ts, etc., je pense que ça mérite un peu de code-splitting également. J'ai pas encore réfléchi, mais avoir un seul fichier dans lequel est défini à la fois l'endpoint du webhook lydia, de l'échange code-token pour l'oauth, de la page de maintenance, etc. c'est vraiment déugueu.
Documenter tout
Ça va de soi ;)
Y'a l'air d'avoir un site pas mal pour autogénérer un site de documentation (parce que le playground GraphiQL c'est pas ouf pour juste voir tout ce qui existe). Mais au pire onpeut créer notre propre truc autogénéré, comme ça on choisi genre l'ordre d'apparition des types / queries / etc.
Pk pas grouper par module en utilisant les dossiers qu'on a déjà dans le code source?
Des schémas zod pour une validation symmétrique
L'idée est d'exporter de src/<module>/types/<type name>.ts
un schéma zod pour chaque type input, et d'utiliser le schéma à la fois pour le validate
côté API et le formulaire côté front avec SuperForms
Les fonctions de l'API pour afficher/cacher symmétriquement
L'idée est d'importer de src/<module>/permissions/<type name>.ts
des fonctions de la forme userCan<action><type>
pour chaque action qu'on peut faire sur un type, et de les utiliser à la fois pour afficher/cacher les boutons côté front et pour les authScopes côté API.
Splitter en composants non-réutilisables les pages
Pareil, bcp trop de code. Histoire de juste avoir des fichiers plus petits, go splitter des bouts de pages dans des composants qu'on met à côté du +page.svelte
. Par contre on importe jamais de composants ailleurs que dans le +page.svelte
, dans ce cas faut les mettres dans src/lib/components/
.
Houdini
On définit nos requirements en terme de données avec fragment(...)
au niveau des composants, et on fout tout ce qu'il faut dans les +page.gql
.
Un peu de CI ?
- autofix.ci pour gitlab (merchi gotier)
- pk pas auto-deploy sur staging les nouvelles versions quand ça build un tag sur main?
- encore plus stylé: auto-deploy
<branch-name>.churros.k8s.inpt.fr/
pour les merge requests?