How daybook.cloud migrated to @tailng-ui/components
From Angular Material and AG Grid to a lighter, themeable, Angular-first component system.
daybook.cloud is a bookkeeping and finance management application. The product includes real-world business screens: organizations, branches, financial years, ledger heads, invoices, journals, banks, items, employees, reports, and reconciliation workflows. These screens need forms, tables, filters, dialogs, layout primitives, and consistent UI behavior across the application.
Angular Material for forms and layout, AG Grid for complex tables.
@tailng-ui/components with TailNG table, form controls, overlays, and theme tokens.
Public site at daybook.cloud, app login at app.daybook.cloud, and frontend source on GitHub.
Why we started the migration
Angular Material and AG Grid are strong libraries, but daybook.cloud needed more control over styling, layout, and application-specific behavior. We wanted a component system that felt native to our product, instead of repeatedly overriding external component styles.
- Styling friction: overriding deeply nested Material styles often became harder than building the UI we wanted.
- Product consistency: finance screens need consistent spacing, borders, filters, empty states, and form layouts.
- Ownable components: we wanted components that could be adjusted quickly when real product screens exposed gaps.
- Angular-first direction: TailNG is built around modern Angular, signals, simple templates, and composable UI primitives.
What changed in the UI stack
The migration was not about replacing one component name with another. It was about simplifying the UI architecture. Tables, forms, buttons, dialogs, inputs, and layout pieces moved toward a single TailNG design language.
| Area | Before | After |
|---|---|---|
| Tables | AG Grid / Material table patterns | TailNG table with product-specific APIs |
| Forms | Angular Material form fields | TailNG form-field, input, select, autocomplete, and related controls |
| Styling | Material theme overrides and custom CSS patches | Theme tokens, flexible classes, and component slots |
| Ownership | Adapt to external component constraints | Adjust TailNG components based on actual app needs |
Replacing grid-heavy screens
daybook.cloud has many list screens: invoices, customers, ledgers, items, banks, branches, journals, and more. These screens need predictable table behavior, but not every screen needs a heavy enterprise grid runtime.
- Column configuration from TypeScript.
- Sortable columns and server-side list query support.
- Pagination, loading states, empty states, and error states.
- Action columns for edit, delete, view, print, and workflow actions.
- Simple styling that looks closer to a clean spreadsheet than a heavy data grid.
TailNG table gives us a smaller and more focused abstraction for business CRUD screens. It keeps the API close to Angular templates and avoids carrying a large grid mental model into every page.
Migrating forms from Material controls
Finance applications are form-heavy. Invoice creation, ledger setup, organization settings, branch details, bank accounts, tax configuration, and reconciliation workflows all depend on clear forms.
- Material form-field wrappers.
- Material-specific appearance constraints.
- Custom CSS overrides for border, focus, spacing, and density.
- Different patterns across older screens.
- TailNG form-field with predictable label and message layout.
- Theme-safe input, select, autocomplete, date, and number controls.
- Slot-based styling for product-specific adjustments.
- Consistent behavior across create, edit, and delete flows.
Slots made customization practical
One important reason for the migration was micro-styling. We did not want every customization to become a global CSS override. TailNG components expose named slots so individual parts can be styled where the component is used.
<tng-form-field
label="Customer"
[slot]="{
root: 'mb-4',
label: 'font-semibold',
control: 'bg-bg text-fg border-border'
}"
>
<input tngInput formControlName="customerName" />
</tng-form-field>This gives us local control without breaking the component contract. The app can still use shared components, while individual screens can adjust small visual details when needed.
daybook.cloud became the proving ground
TailNG is not being built only from isolated demo pages. daybook.cloud gives us real screens, real data, and real edge cases. When a component does not work well in a finance workflow, we improve the component and bring that learning back into TailNG.
- Invoice forms helped improve form-field and input composition.
- Ledger and item pages helped refine reusable list and table patterns.
- Business workflows helped validate dialogs, buttons, loading states, and empty states.
- Theme requirements helped keep components token-based instead of hardcoded to one design.
How we approached the migration
We did not migrate everything in one large rewrite. The safer path was screen-by-screen replacement, starting with repeated CRUD pages where the UI patterns were already clear.
1) Identify repeated Material / AG Grid patterns
2) Extract the common behavior needed by daybook.cloud
3) Build or improve the matching TailNG component
4) Migrate one screen
5) Fix gaps found in real usage
6) Reuse the improved component in the next screenThis kept the migration practical. Each migrated page improved the component system, and each improved component made the next page easier.
What improved after the migration
Less CSS fighting
Components are easier to style because TailNG is designed around tokens, slots, and plain Angular usage.
More consistent screens
Tables, forms, actions, spacing, and states now follow the same product language.
Better ownership
When a screen needs a feature, we can improve the component instead of patching around a black box.
A stronger TailNG roadmap
Real application usage helps prioritize the components and APIs that matter most.
This is not an anti-Material or anti-AG Grid story
Angular Material and AG Grid are mature and useful tools. This migration was about product fit. daybook.cloud needed a UI system that was easier to own, easier to theme, and closer to the way we build modern Angular applications.
TailNG is our answer to that need: Angular-first components, theme-safe styling, reusable primitives, and practical APIs shaped by real product screens.
Next
Explore TailNG components, visit the daybook.cloud website, open the app, or review the frontend source code.