Process Utilisateurs
Cette fiche décrit le parcours complet pour intégrer la brique Utilisateurs dans votre application : de la recherche paginée jusqu'à l'affichage d'un profil enrichi, en passant par la gestion des erreurs courantes.
Cas d'usage guide : un écran de gestion RH qui permet à un manager de retrouver un collaborateur, consulter ses infos, et basculer vers les publications / demandes associées. Tous les exemples ci-dessous sont exécutables en direct.
Vue d'ensemble du flux
┌──────────────┐ 1. search ┌─────────────┐ 2. select ┌──────────────┐
│ Liste UI │ ────────────▶ │ users(...) │ ────────────▶ │ user(id) │
│ (paginée) │ │ paginée │ │ + relations │
└──────────────┘ └─────────────┘ └──────┬─── ────┘
│ 3. drill
▼
┌──────────────┐
│ posts/todos │
│ albums (lazy)│
└──────────────┘
Trois étapes, trois bonnes pratiques :
- Lister avec une pagination — ne jamais charger la liste complète.
- Afficher le détail en un seul appel — regrouper les champs utiles.
- Charger les relations à la demande, rarement en même temps que l'étape 2.
Étape 1 — Recherche paginée
Toujours passer par options.paginate : le backend impose une limite stricte
(100) et renverra une erreur si on l'omet sur des gros volumes.
Pagination — règle d'or
| Limit | Cas d'usage | Performance attendue |
|---|---|---|
| 5 – 10 | Autocomplétion, liste déroulante | < 50 ms |
| 20 – 50 | Tableau standard | < 200 ms |
| 100 | Export / synchro batch | < 1 s |
| > 100 | ❌ refusé — utiliser un curseur batch |
Pour un export, préférez plusieurs pages de 100 à une requête massive — l'API tolère mieux les petits lots et vous gardez la main sur les erreurs partielles.
Étape 2 — Fiche détail
Regrouper dans une seule requête les champs affichés sur l'écran profil. Chaque champ inutilisé côté UI est un coût inutile côté backend.
Pièges courants
id: "0"renvoienullsans erreur — traiter le retour nul côté client.addresspeut être partiellement renseigné : chaque sous-champ est optionnel. Toujours vérifier côté UI avant concaténation.
Étape 3 — Relations à la demande
Charger posts / todos / albums seulement quand l'utilisateur ouvre l'onglet
correspondant. Le type PostsPage est paginé — même règle d'or que l'étape 1.
Aller plus loin
Une fois le process maîtrisé, ouvrez le playground pour composer vos propres requêtes — autocomplétion, validation et documentation inline, le tout au même endroit.
Voir aussi
- Process Posts — cycle de vie du contenu, lié à un
User - Hub API — fiches, queries, mutations et types sur une seule vue