Rien ne change dans l’api-sdk. Tout le client en sort.

À gauche : ce qu’on écrivait déjà. À droite : ce que createApiOperationClient en génère, pour les 44 contrôleurs.

Quatre méthodes par query, une clé derrière.

La clé est toujours ['api', controller, operation, input] : même input, même entrée de cache — quel que soit l’endroit du code.

defineQueryConfig — une fois par app, pour toutes les queries.

Le moteur est commun ; chaque app décide fraîcheur, retry, invalidation, préchauffage et persistance. Les écrans n’en savent rien.

Même contrat, quatre politiques.

Ce que chaque config/query.ts a choisi, et pourquoi.

Les intégrations sont des capacités, pas des plugins.

Désactivé par défaut dans la couche partagée. Une app active ; le plugin propriétaire lit la config avant d’injecter le moindre script.

Notre useQuery : TanStack, plus ce qui manquait.

Un getter d’options, un second argument, un retour étendu — la même signature dans les quatre apps.

Six choses qu’on n’écrit plus à la main.

Extraits réels des apps — un onglet par capacité. Chacun remplace un watch, un store ou un refetch d’autrefois.

Un queryOptions, six consommateurs.

Partout où une donnée entre, c’est la même déclaration — donc la même clé, le même cache, la même invalidation.

Écrire, puis laisser invalider.

Avant : le code appelant décide quoi recharger. Après : le contrôleur de la mutation devient périmé, selon la politique de l’app.

La page déclare ses données. Le lien les charge.

Au survol d’un lien, Nuxt exécute le plan de la page destination dans le même cache que useQuery lira à l’arrivée.

Une option, une liste, ou un plan.

Le nom de route type les params ; le contexte donne client et route (plus prismic sur market-front).

Chaque page déclare son plan. Chaque lien le lance.

Le résultat mesuré en production, et un plan de page réel : entité + catalogue préparés ensemble.

Un DataList pour la découverte : la même famille, d’autres clés.

Ce que chaque zone de la page catalogue doit à une clé de defineCatalogSchema. En bleu : ce qui n’existe pas côté DataList.

Un schéma, trois consommateurs.

Le composant, le SSR et le prefetch lisent la même définition — un filtre change une fois.

Deux composables. Tout dérive de l’entité.

useMarketPageSeo pour une page, useMarketItemSeo pour une fiche : six sorties réactives.

Une image de partage = un composant Vue.

defineOgImage reçoit des props réactives ; le composant Takumi est rendu côté serveur en JPG.

Un module par corvée. On configure, on ne code pas.

Ce que chaque module sert en plus de la page — robots, sitemaps, images OG, JSON-LD, llms.txt — sans une ligne de plomberie dans market-front.

Une fiche = un en-tête, des sections, un rail.

Organisation, item, séance, contrat, facture, utilisateur : la même structure, opérée par un composant partagé — <EntityDetailShell>.

Vous déclarez trois choses. Le shell fait le reste.

Le code métier dit quoi charger, comment la fiche est structurée, et ce qu’un enregistrement fait. Tout le cycle de vie est partagé.

L’essentiel d’abord, le reste ensuite, les tables à la demande.

Chronologie d’une fiche organisation : ce qui part à l’ouverture, ce qui attend ready, ce qui attend la section.

defineEntityLoader — chaque ressource nourrit une partie de la fiche.

Un composable par entité. Trois étages, quatre méthodes. À droite : où chaque déclaration atterrit.

Trois étages, un compteur.

Quand chaque étage part, ce qu’il bloque, et la déclaration qui va avec.

Le loader est aussi le plan de prefetch.

Survoler une ligne de la liste charge l’essentiel de la fiche — dérivé du loader, jamais réécrit. Six lignes par page, une fois.

defineEntityDetails — des groupes, des sections, quatre types.

La config se lit comme le plan de la fiche. Chaque section a un type ; le shell sait rendre chacun.

L’en-tête est de la donnée, pas du template.

Nature, référence, titre, statut, métadonnées : cinq clés dans la config. Le shell les rend, gère le chargement, les liens et les valeurs absentes.

Le shell, plus un slot par section sur mesure.

Le template ne contient que les sections qu’aucun type générique ne couvre — ici une table embarquée qui a besoin de son bouton.

Une section formulaire, quatre états — tous automatiques.

Vous fournissez un schéma et un submit. La liaison, la détection, le commit et la remise à zéro sont le travail du shell.

Quatre clés, un contrat d’édition.

Avant : panneaux, flags de dirty, barre globale, rechargements. Après : une déclaration et une fonction submit qui renvoie un booléen.

Une relation = le même schéma que la liste, en compact.

Trois déclarations : la table différée + son compteur dans le loader, la section dans la config, les colonnes compactes dans le schéma d’entité.

Le rail sait tout avant les tables.

Compteurs, position, sections modifiées, alertes : le rail dérive de la config et des ressources — rien à câbler.

Le même contrat, sans formulaire.

Photos d’un item, ressources d’une séance : un composant maison enregistre trois choses et reçoit pied, verrou et garde.

Hiérarchie & procurations : trois surfaces → une section.

Un cas métier riche qui n’a rien demandé au shell : parent et enfants sont des champs, la matrice est un champ custom, la transaction vit dans submit.

Ajouter une fiche, ou une section.

Quatre fichiers, dans cet ordre.

Un dossier par entité. Un fichier par rôle.

Jamais pour un seul appelant : pas d’helper, de constante ou de type créé pour un consommateur unique. Une déclaration réutilisable vit chez son propriétaire.

Un champ qui cherche dans toute la base.

L’admin opère sur tout le jeu de données : les sélecteurs paginent côté serveur. Le champ déclare deux requêtes, le moteur fait le reste.

Même contrat, en arbre — et un sélecteur par entité.

Racines paginées, branches chargées à l’ouverture, chemin complet reconstitué pour la valeur enregistrée.

La table en pièces détachées.

Même schéma, même moteur — mais vous posez chaque pièce où vous voulez. Pour les écrans admin qui ne rentrent pas dans le DataList standard.

Trois couches. Deux sont de la configuration.

Coquille pré-cachée · référentiel = cache Query persisté · brouillons locaux publiés plus tard.

les mutations restent en ligne — le brouillon local est la file d’attente

Quoi persister, comment, pour qui.

Une liste blanche d’opérations, un persister IndexedDB scopé, un préchargement au login.

Local d’abord. Publication reprise.

Le cycle d’un brouillon, et ce qu’un écran en voit.