In 2025, I started working on ngx-crud-builder, an Angular library designed to generate CRUD forms and data tables from a simple configuration, instead of rewriting the same create, edit, delete and listing screens over and over.

The demo is available here.

The starting point

On most professional projects, a large share of front-end development time goes into very similar screens: a form to create or edit an entity, a table to list it, a confirmation dialog to delete it, sometimes a change history. The business logic changes, but the mechanics stay the same.

The idea behind ngx-crud-builder is to declare an entity once (its fields, their types, their validations) and let the library take care of the form, the table, the HTTP calls and the related interactions.

Library architecture

The repo is an Angular monorepo with two projects:

  • ngx-crud-builder, the published library
  • ngx-crud-builder-demo, a demo application

Inside the library, the code is organized in three main blocks:

src/crud/
├── core/     # models, utilities and cross-cutting services
├── form/     # dynamic form generation
└── table/    # configurable data table

The key point of the architecture is the separation between business logic (validation, HTTP calls, permissions handling) and visual rendering, delegated to interchangeable adapters:

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

Three adapters are available today: Optimus UI (the most complete), Angular Material (through a separate entry point so the dependency isn't forced on everyone) and a native HTML renderer, lighter but still experimental. Each adapter provides its own implementation of the form fields and the table, without touching the business logic.

Use cases

The demo illustrates three concrete scenarios:

  • / an interactive form, to explore the different field types
  • /table a table configurator (sorting, filters, pagination, columns)
  • /full-example a complete IT request workflow example, with access rights management, saved views and history

In practice, the library already covers fairly advanced needs: more than 15 field types, data export, archiving/restoring instead of permanent deletion, fine-grained permissions (ACL_ADAPTER) per feature, and per-user persistence of a table's display preferences.

Recent improvements

The latest versions mainly focused on broadening the rendering adapters:

  • the Material adapter has been completed to cover all field types and now handles sorting, filtering and lazy loading in the table
  • the native adapter followed the same path, with a visual harmonization of all controls through dedicated CSS variables
  • @angular/material has become a truly optional dependency, isolated in a separate entry point, so it isn't imposed on projects that don't use it

What's next?

The Material and native adapters still lag behind Optimus UI on a few points: column resizing, table state persistence, context menu. Closing that gap is the next logical step, so that choosing an adapter is really a matter of visual preference, not of missing features.

In the longer term, I'd also like to enrich history management and explore an inline editing mode in the table, in addition to the current dialog.

Conclusion

Building a generic library, and not just a set of components for a given project, forces you to ask architecture questions that are easy to dodge otherwise: how to separate rendering from logic, how far to configure without adding complexity, what to make optional. ngx-crud-builder isn't set in stone, but it already answers a recurring need: stop rewriting the same CRUD screens.