Créer des applications pilotées par les données avec React Admin

Si vous avez déjà construit un tableau de bord d’administration de zéro — en câblant manuellement les tableaux, les formulaires, la pagination et les appels API — vous savez combien de code répétitif il faut écrire avant même d’aborder la moindre ligne de logique métier. React Admin simplifie tout cela en vous fournissant un framework structuré pour créer des applications CRUD au-dessus de n’importe quelle API. Cet article explique son fonctionnement, en se concentrant sur l’architecture qui le rend véritablement agnostique du backend et réutilisable.

Ce qu’est réellement React Admin

React Admin n’est pas un template d’interface utilisateur. C’est un framework React spécialement conçu pour les tableaux de bord d’administration pilotés par les données et les outils internes. Il fournit des composants pour lister, créer, modifier et supprimer des enregistrements, mais sa véritable valeur réside dans la façon dont il sépare votre couche de données de votre couche UI.

À la base, React Admin v5 s’appuie sur React Query, react-hook-form et react-router. Il utilise MUI par défaut, mais n’y est pas limité — React Admin supporte une utilisation headless, ce qui signifie que vous pouvez apporter votre propre bibliothèque de composants si nécessaire.

Les trois blocs de construction : Admin, Resource et dataProvider

Chaque application React Admin commence avec trois concepts :

• <Admin> — le composant racine qui connecte tout ensemble
• <Resource> — associe un nom à un ensemble de vues CRUD et un endpoint API
• dataProvider — l’adaptateur entre React Admin et votre backend

import { Admin, Resource } from "react-admin"
import { dataProvider } from "./dataProvider"
import { MovieList } from "./MovieList"
import { MovieEdit } from "./MovieEdit"

const App = () => (
  <Admin dataProvider={dataProvider}>
    <Resource name="movies" list={MovieList} edit={MovieEdit} />
  </Admin>
)

Lorsqu’un utilisateur navigue vers la liste des films, React Admin appelle dataProvider.getList("movies", params). Lorsqu’il modifie un enregistrement, il appelle dataProvider.update("movies", params). L’interface utilisateur ne communique jamais directement avec votre API.

Comment fonctionne le dataProvider de React Admin

Le dataProvider repose sur neuf méthodes principales : getList, getOne, getMany, getManyReference, create, update, updateMany, delete et deleteMany. Chaque méthode reçoit un objet de requête et retourne une Promise, et les providers peuvent être étendus avec des méthodes supplémentaires si nécessaire.

const dataProvider = {
  getList: async (resource, params) => {
    const { page, perPage } = params.pagination
    const { field, order } = params.sort
    const url = `${apiUrl}/${resource}?page=${page}&perPage=${perPage}&sort=${field}&order=${order}`
    const { json, headers } = await httpClient(url, { signal: params.signal })
    return {
      data: json,
      total: parseInt(headers.get("content-range").split("/").pop(), 10),
    }
  },
  // ...autres méthodes
}

React Admin ne se soucie pas de savoir si votre backend est REST, GraphQL, Supabase ou même IndexedDB. Tant que chaque enregistrement possède un champ id cohérent et que votre dataProvider retourne la forme attendue, cela fonctionne. Des adaptateurs pré-construits existent pour les backends courants — ra-data-simple-rest, ra-data-graphql et d’autres — vous n’avez donc souvent pas besoin d’en écrire un de zéro.

Gestion de l’authentification

L’authentification n’est pas intégrée dans le dataProvider. React Admin utilise un authProvider séparé pour la connexion, la déconnexion et les vérifications de permissions. Un pattern courant consiste à stocker un token après la connexion et à le lire dans votre dataProvider lors des requêtes, mais React Admin supporte également l’intégration avec des fournisseurs d’identité externes.

const httpClient = (url, options = {}) => {
  options.user = {
    authenticated: true,
    token: localStorage.getItem("token"),
  }
  return fetchUtils.fetchJson(url, options)
}

Créer des vues de liste et d’édition

Une fois votre dataProvider configuré, la création de vues est principalement déclarative. Pour les vues de liste, le composant <Datagrid> de React Admin affiche des colonnes basées sur les composants de champs que vous composez. Notez que <Datagrid> est toujours largement utilisé, mais les versions plus récentes introduisent également <DataTable> comme alternative plus moderne.

import { List, Datagrid, TextField, DateField, ReferenceField } from "react-admin"

export const MovieList = () => (
  <List>
    <Datagrid rowClick="edit">
      <TextField source="title" />
      <DateField source="release" />
      <ReferenceField source="director_id" reference="directors">
        <TextField source="lastname" />
      </ReferenceField>
    </Datagrid>
  </List>
)

<ReferenceField> appelle automatiquement dataProvider.getMany("directors", ...) pour résoudre les enregistrements liés — aucune récupération manuelle requise.

Les formulaires d’édition suivent le même pattern en utilisant <Edit> et <SimpleForm> :

import { Edit, SimpleForm, TextInput, DateInput } from "react-admin"

export const MovieEdit = () => (
  <Edit>
    <SimpleForm>
      <TextInput source="title" />
      <DateInput source="release" />
    </SimpleForm>
  </Edit>
)

Quand vous avez besoin de logique personnalisée

Pour un comportement spécifique à une ressource — comme supprimer des enregistrements liés avant qu’un parent ne soit supprimé — React Admin fournit withLifecycleCallbacks :

import { withLifecycleCallbacks } from "react-admin"

export const dataProvider = withLifecycleCallbacks(baseDataProvider, [
  {
    resource: "movies",
    beforeDelete: async (params, dp) => {
      const { data: reviews } = await dp.getList("reviews", {
        filter: { movie_id: params.id },
        pagination: { page: 1, perPage: 1000 },
        sort: { field: "id", order: "DESC" },
      })
      await dp.deleteMany("reviews", { ids: reviews.map((r) => r.id) })
      return params
    },
  },
])

Cela maintient votre logique métier proche de la couche de données sans la disperser dans les composants.

Ce que React Admin ne fait pas nativement

Quelques points à connaître avant de vous engager :

• RBAC (contrôle d’accès basé sur les rôles à granularité fine) nécessite le module entreprise ; les vérifications de permissions basiques sont gérées via l’authProvider
• Les mises à jour en temps réel nécessitent un data provider compatible temps réel et une configuration supplémentaire
• Les uploads de fichiers nécessitent une logique dataProvider personnalisée pour gérer multipart/form-data

React Admin est également compatible avec des frameworks comme Next.js (incluant à la fois Pages Router et App Router) et supporte des solutions de routage alternatives au-delà de sa configuration par défaut.

Conclusion

La force de React Admin réside dans son abstraction dataProvider. Une fois que vous avez implémenté ces méthodes principales contre votre API, vous obtenez un tableau de bord d’administration CRUD entièrement fonctionnel avec tri, filtrage, pagination et gestion des relations — sans avoir à construire tout cela vous-même. Commencez avec un adaptateur pré-construit s’il correspond à votre backend, écrivez-en un personnalisé sinon, et ajoutez l’authentification et les callbacks de cycle de vie au fur et à mesure que votre application évolue.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.