2025, la construction de ma librairie de gestion des CRUDs en Angular

En 2025, j'ai commencé à travailler sur ngx-crud-builder, une librairie Angular pensée pour générer des formulaires et des tableaux de données CRUD à partir d'une simple configuration, plutôt que de réécrire à chaque fois les mêmes écrans de création, édition, suppression et listing.

La démo est disponible ici.

Le point de départ

Sur la plupart des projets professionnels, une grande partie du temps de développement front part dans des écrans très similaires : un formulaire pour créer ou éditer une entité, un tableau pour la lister, un dialogue de confirmation pour la supprimer, parfois un historique des modifications. La logique métier change, mais la mécanique reste la même.

L'idée de ngx-crud-builder est donc de déclarer une entité une seule fois (ses champs, leurs types, leurs validations) et de laisser la librairie se charger du formulaire, du tableau, des appels HTTP et des interactions associées.

Architecture de la librairie

Le repo est un monorepo Angular avec deux projets :

• ngx-crud-builder, la librairie publiée
• ngx-crud-builder-demo, une application de démonstration

À l'intérieur de la librairie, le code est organisé en trois grands blocs :

src/crud/
├── core/     # modèles, utilitaires et services transverses
├── form/     # génération de formulaires dynamiques
└── table/    # tableau de données configurable

Le point clé de l'architecture, c'est la séparation entre la logique métier (validation, appels HTTP, gestion des droits) et le rendu visuel, délégué à des adaptateurs interchangeables :

// app.config.ts
providers: [
  provideOptimus({ theme: { preset: MyPreset } }),
  ...provideCrudRenderer('optimus-ui'), // ou 'material', ou 'native'
]

Trois adaptateurs sont disponibles aujourd'hui : Optimus UI (le plus complet), Angular Material (via un entry point séparé pour ne pas imposer la dépendance à tout le monde) et un rendu HTML natif, plus léger mais encore expérimental. Chaque adaptateur fournit sa propre implémentation des champs de formulaire et du tableau, sans toucher à la logique métier.

Cas d'usage

La démo illustre trois scénarios concrets :

• / un formulaire interactif, pour explorer les différents types de champs
• /table un configurateur de tableau (tri, filtres, pagination, colonnes)
• /full-example un exemple complet de workflow de demandes IT, avec gestion des droits d'accès, vues sauvegardées et historique

En pratique, la librairie couvre déjà des besoins assez avancés : plus de 15 types de champs, export de données, archivage/restauration plutôt que suppression définitive, gestion fine des permissions (ACL_ADAPTER) par fonctionnalité, et persistance des préférences d'affichage d'un tableau par utilisateur.

Améliorations récentes

Les dernières versions ont surtout porté sur l'élargissement des adaptateurs de rendu :

• l'adaptateur Material a été complété pour couvrir tous les types de champs et gère désormais le tri, le filtrage et le chargement différé dans le tableau
• l'adaptateur natif a suivi le même chemin, avec une harmonisation visuelle de tous les contrôles via des variables CSS dédiées
• @angular/material est devenu une dépendance réellement optionnelle, isolée dans un entry point séparé, pour ne pas l'imposer aux projets qui ne l'utilisent pas

Et la suite ?

Les adaptateurs Material et natif restent en retrait par rapport à Optimus UI sur certains points : redimensionnement des colonnes, persistance d'état du tableau, menu contextuel. Combler cet écart est la prochaine étape logique, pour que le choix d'un adaptateur soit vraiment une question de préférence visuelle, pas de fonctionnalités manquantes.

À plus long terme, j'aimerais aussi enrichir la gestion de l'historique et explorer un mode d'édition inline dans le tableau, en plus du dialogue actuel.

Conclusion

Construire une librairie générique, et pas seulement un ensemble de composants pour un projet donné, pousse à se poser des questions d'architecture qu'on esquive facilement autrement : comment séparer rendu et logique, jusqu'où configurer sans complexifier, quoi rendre optionnel. ngx-crud-builder n'est pas figée, mais elle répond déjà concrètement à un besoin récurrent : arrêter de réécrire les mêmes écrans CRUD.