DEV Community: Zonaib Bokhari

Ef-timelapse: a time-travel viewer for your EF Core schema published

Zonaib Bokhari — Thu, 06 Aug 2026 10:29:14 +0000

A few weeks ago I was staring at a table in a database, trying to figure out when a column showed up and why a particular foreign key existed. The answer was in there somewhere, spread across thirty-odd migration files, and finding it meant opening them one by one. EF Core migrations are great at telling you what changed — one file, one point in time. They're not great at telling you how something evolved.

Update: v0.2.0 adds an entity relationship visualizer

Since publishing the first version, I added a Git-mode entity relationship graph for scaffolded EF/database-first projects. The tool no longer only answers “what changed in this entity over time?” It can now also answer “how is this entity connected to the rest of the model?”

In Git scaffold mode, ef-timelapse now infers relationships from navigation properties and shows:

a relationship graph overview of the model
a focused entity view with the selected entity’s properties and direct relationships
a timeline filtered to only the checkpoints where that focused entity changed
relationship tooltips in plain language, for example Order.Items one-to-many OrderItem
zoom, pan, and resizable focused cards for larger models

This is especially useful for database-first projects that do not have EF migrations. You can point the tool at the scaffolded project, scrub through Git history, and inspect both the property changes and relationship shape over time.

Release: https://github.com/xonaib/ef-timelapse/releases/tag/v0.2.0

Repository: https://github.com/xonaib/ef-timelapse

Relationship graph overview

Focused entity graph

Relationship tooltip

So I built a small tool to fix that for myself: ef-timelapse. It replays your EF Core schema history — either from migration files, or from Git history if you're on a scaffolded/database-first setup with no migrations at all — into one browser-based timeline you can scrub through, search, and diff.

dotnet tool install -g ef-timelapse
ef-timelapse serve C:\Path\To\YourProject

That's really the whole setup. It figures out on its own whether your project uses migrations or is a scaffolded project tracked in Git, and serves the same interactive viewer either way.

Two ways to look at schema history

If you've got a Migrations folder, migration mode parses every file with Roslyn and replays each migrationBuilder call in order. You get a slider that walks through every migration, showing exactly which tables and columns it touched at each step:

If you don't — a lot of database-first projects scaffold their model classes straight from an existing database and never touch migrations — Git scaffold history mode walks your Git history instead and replays how the generated model files changed commit by commit. Same idea, different source of truth.

Both modes drop you into the same viewer. Same slider, same search box, same detail panels — just backed by different data underneath.

Finding when something actually changed

The feature I built for myself and now use the most is the per-entity (or per-table, in migration mode) history panel. Instead of clicking through commits one at a time hoping to spot when a property got added, you search for the class or table by name and get every point in history it changed, newest first:

Same thing works for tables and columns in migration mode — search "Orders" and see every migration that touched it, in one place, instead of opening files one by one:

It shows you the actual diff, not just a summary

In Git mode, clicking a changed file at any commit shows the real inline diff — added and removed lines highlighted — not just "+12 -3" and nothing else:

Does it hold up on a real codebase?

I didn't want to just demo this against a toy project with five commits, so I pointed it at eShopOnWeb, Microsoft's reference ASP.NET Core + EF Core sample app — 455 real commits, real entities, real migrations. Every screenshot in this post is from that run. The first time you point Git mode at a repository like that, it has to walk the full history and index it, so you'll see a progress modal while that happens:

After that first pass it's cached on disk, so running it again against the same repo starts instantly. If you're actively working on the project, --watch picks up file changes live too.

What it deliberately doesn't do

I'd rather it tell me "I don't know" than guess wrong. If a migration operation depends on something the parser can't statically resolve — a local variable, a helper method call, raw SQL, a branch in the code — it gets reported as an unsupported step with the exact source line, instead of being silently skipped or guessed at. It also only replays the forward path (Up()); rollback history isn't visualized. This is a read-only exploration tool, not a migration generator.

Try it

dotnet tool install -g ef-timelapse
ef-timelapse serve <path-to-your-project>

It's open source, MIT-licensed: github.com/xonaib/ef-timelapse. If you run it against your own project and it chokes on a migration pattern or gets a schema shape wrong, I'd genuinely like to hear about it — open an issue, or a PR if you've already got a fix in mind.

ng-loom: a dependency graph for your Angular app, as a single HTML file

Zonaib Bokhari — Thu, 06 Aug 2026 10:12:57 +0000

On a large Angular workspace at work, I needed to know what actually depended on a shared service before I touched it. grep finds text, not relationships. The routing config tells you what loads, not what it pulls in. And most "architecture diagram" tools want your code in the cloud, or want you to hand-maintain a diagram that's stale within a week.

So I built ng-loom — a CLI that statically analyzes an Angular workspace and spits out a single, self-contained HTML file with the whole dependency graph in it. No server, no account, no uploading your source anywhere. You run it, you get a report, you open it in a browser.

Update: ng-loom 0.2.0 is now published.

The new release improves correctness and safer sharing. Reports can now be generated with --portable to strip local absolute paths and source snippets, template parsing prefers the target project's installed @angular/compiler, duplicate class/import/DI/route references resolve by declaration identity, and ambiguous template selectors are surfaced with heuristic confidence instead of silently picking one.

Also corrected: current lazy route support covers loadComponent; loadChildren is not supported yet. Nx/full monorepo workspace support is still planned.

What it actually does

Point it at an Angular CLI project:

npx ng-loom ./path/to/angular-project --out report.html

and it walks the workspace with ts-morph, finds every component, directive, pipe, service, and NgModule, and maps out how they connect: standalone imports, NgModule imports/exports/declarations, constructor DI and inject() calls, hostDirectives, lazy routes via loadComponent. Template usage isn't regex-matched against your HTML — it runs your actual templates through @angular/compiler's real parser, so @if/@for/@switch/@defer blocks, structural directives, and attribute selectors all resolve correctly instead of getting silently missed.

Every edge in the graph carries the file, line, and column it came from, plus a vscode:// link straight to the source. So when the report tells you ArticleComponent injects UserService, you're not taking its word for it — you can jump to the exact line.

The report itself has a few views:

A folder/package overview that treemaps your codebase into clusters, so you can see at a glance where the size and complexity actually live before drilling into a single file.
A node focus view with a Details panel — imports, injected services, host directives, template usages, all with source snippets.
Trace relation, which answers "how does A actually reach B?" — it finds every path between two artifacts, not just the first one it stumbles on, which matters more than you'd think once you're a few layers of indirection deep.

Here's what that looks like against a real app (ngx-admin, 294 nodes, 340 edges):

Why a static HTML file

This was the one design decision I didn't waver on. I didn't want a dashboard, a login, or a background service watching your repo. I wanted something you could generate, drop in a PR description, email to a teammate, or just keep around as a snapshot of "this is what the app looked like in March." A plain HTML file with the graph data embedded in it does all of that without asking anything of the person opening it.

The tradeoff is that it's a snapshot, not a live view — regenerate it after a big refactor and it's current again, but it won't update itself while you work. That's a fair trade for something that requires zero setup on the receiving end.

What's there and what isn't

Being upfront about the current state: pipe usage in templates ({{ value | somePipe }}) isn't tracked as an edge yet, class-binding selectors ([ngClass], [class.x]) aren't matched, and there's no Nx monorepo support — it expects a standard Angular CLI tsconfig.app.json/angular.json layout. Route parsing covers the common static patterns, not every dynamic route construction you could write. These are documented, not hidden, and they're the next things on the list.

What is there: real Angular template AST parsing (not regex), signal-based input()/output()/model() API extraction with aliases, the experimental @Service() decorator alongside @Injectable(), and a Playwright test suite covering the actual generated report in a real browser, not just unit tests against the analyzer.

Try it

npx ng-loom ./path/to/your-angular-app --out report.html

It's on npm as ng-loom, and the source is on GitHub at xonaib/ng-loom. If you run it against something interesting — or it chokes on your workspace layout — I'd genuinely like to hear about it. Open an issue, or just tell me what broke.

I built a form builder that lives inside your AI chat

Zonaib Bokhari — Tue, 05 May 2026 10:06:20 +0000

Context switching is the thing that kills me.

I'm mid-conversation with Claude, figuring something out, and then I need to collect responses from a few people. So I open Typeform in another tab, build the form, copy the link, come back. By which point I've completely lost the thread of what I was thinking.

So one weekend I just decided to fix it for myself. The result is MCP Forms — you describe a form to Claude, it builds it and hands you a live link, and you can read the responses back later. All in the same chat window.

Here's what it actually looks like

You just talk to it:

Create a job application form. Ask for full name, email, and experience level 
(Junior / Mid / Senior). If they select Senior, show a field asking about 
their leadership experience.

Claude calls the tool, the form gets generated, and you get a shareable link back — or an inline preview card if you're in a supported client:

The form itself is clean, works on mobile, has a light/dark toggle. The conditional logic works exactly as you'd expect — select Senior, the leadership field appears:

When you want to see who filled it out:

Show me submissions for the job application form
Export as CSV

What it supports

Field types: text, email, number, textarea, dropdown (select), radio buttons, checkboxes, and date. Claude picks the right type from your description — ask for an email field and it generates type: email with validation, ask for a yes/no question and it generates a radio group.

Conditional logic: any field can have a showIf rule that makes it appear only when another field has a specific value. Works across field types — radio, dropdown, whatever.

Dark theme: forms default to light, but every form has a built-in theme toggle that respondents can use themselves. You can also set the default at creation time:

Create a feedback form using the dark theme

Updating forms: this one I use a lot. You don't have to rebuild from scratch if something's wrong — just tell Claude what to change:

Add a phone number field to the job application form
Change the experience level options to Junior, Mid, Senior, Lead
Remove the cover letter field

The form updates in place. Same URL, same submissions, just a different shape.

Draft / Publish workflow: forms start as drafts so you can preview before anyone fills them out. You publish explicitly when you're ready to share the link.

Email notifications: get an email on every new submission:

Create a contact form and notify me at you@example.com on each submission

Redirect after submit: send respondents somewhere specific after they hit submit — a thank-you page, back to your site, anywhere:

Create an application form and redirect to https://example.com/thanks after submission

The bit I find genuinely cool about this

Most MCP tools are wrappers around read operations. Search this, summarize that, fetch the other thing. What I liked about building this one is that the AI is actually creating something that persists — a real form at a real URL that other people can fill out, that collects real data.

It sounds small but it's a different kind of thing. The AI isn't just helping you think, it's helping you build.

How I built it

Stack is pretty simple:

Claude Desktop / Claude.ai / Cursor / any MCP client
        │
        │  MCP (stdio or streamable-http)
        ▼
Python MCP Server
        │
        │  HTTP
        ▼
ASP.NET 9 API (on Railway)
        │
        ├── Claude API → JSON form schema
        ├── SQLite for storage
        └── Scriban templates → HTML

The flow that makes it work: when you describe a form, the API calls Claude with a prompt that returns a JSON schema — field types, labels, options, conditional rules. The form renderer takes that schema and generates HTML server-side using Scriban templates. Claude runs exactly once per form, at creation time. Loading the form page doesn't touch the AI API at all.

Conditional logic lives in the schema as showIf rules:

{
  "id": "leadership_experience",
  "type": "textarea",
  "label": "Describe your leadership experience",
  "showIf": { "field": "experience_level", "value": "Senior" }
}

There's a bit of vanilla JS on the form that watches trigger fields and shows/hides dependents. One thing I got wrong the first time — I was using getElementById to find radio button groups, which doesn't work because radio inputs use name not id. Had to fall back to querySelectorAll('[name="..."]'). Classic.

On the security side: MCP endpoints are behind an API key, form view and submit are public (obviously — people need to fill out your forms), server-side validation mirrors the schema rules, rate limiting on submit, XSS handled by Scriban's auto-encoding. Nothing exotic, just the basics done properly.

No install needed if you just want to try it

The MCP server is hosted on Railway with streamable-http transport. Add it as a custom connector in Claude.ai:

https://mcp-forms-production-cdf7.up.railway.app/mcp

Settings → Connectors → Add custom connector. Works the same way in ChatGPT, Cursor, Windsurf.

The webhook thing

Every form can have a webhook URL. On submission, the payload gets POSTed there. If it's a Slack incoming webhook URL, MCP Forms formats the payload as a proper Slack message automatically. Anything else gets raw JSON.

I'm pretty happy with this design decision — one feature, zero native integrations, but it unlocks Slack, Zapier, Make, n8n, and Google Sheets at once. You just tell Claude:

Create a contact form and send submissions to my Slack at 
https://hooks.slack.com/services/...

Submissions land in Slack like:

New submission: Contact Form
• name: Jane Smith
• email: jane@example.com
• message: Interested in your services!
Submitted at 2026-01-15T10:32:00Z

Try it / grab the code

github.com/xonaib/mcp-forms — MIT licensed

You'll need .NET 9, Python, uv, and an Anthropic API key. Self-hosting takes maybe 10 minutes following the README.

A few things still on the list: Notion integration, file upload fields, and proper multi-tenant auth (right now it's single-tenant — one database, one API key). Happy to take PRs or ideas.

Built this mostly on weekends and evening sessions between putting the kids to bed and falling asleep on the couch. If you try it and something's broken, open an issue — I'm actively working on it.

I got tired of copy-pasting the same table code, so I built a library

Zonaib Bokhari — Mon, 20 Apr 2026 08:56:21 +0000

Every Angular project I've worked on has a table. Usually more than one. And every single time I end up writing the same setup — wire up MatSort, wire up MatPaginator, build a SelectionModel for checkboxes, manage filter state somewhere, figure out export again from scratch.
It's not hard, it's just tedious. And when you do it enough times across enough projects, slightly differently each time, you start to wonder why you haven't just extracted it.
So I did. ngx-mat-simple-table — an Angular Material table component that takes a column config and data, and handles the rest.

The core idea

I wanted to go from this (the usual boilerplate situation) to this:

<simple-table
  [tableColumns]="columns"
  [dataSource]="rows"
  [tableConfig]="config"
  (sortChange)="onSort($event)"
  (filterChange)="onFilter($event)"
  (selectionChange)="onSelect($event)"
>
  <st-export filename="tasks" format="xlsx" [allDataProvider]="getAllForExport" />
</simple-table>

Column config is a plain array:

readonly columns: ColumnDef[] = [
  { key: 'select' },
  { key: 'title',    label: 'Title',    hasColumnFilters: true },
  { key: 'assignee', label: 'Assignee', hasColumnFilters: true, filterType: FilterType.DropDown },
  { key: 'status',   label: 'Status',   hasColumnFilters: true, filterType: FilterType.DropDown,
    displayValue: v => String(v).replace(/-/g, ' ').toUpperCase() },
  { key: 'dueDate',  label: 'Due Date' },
];

Fully paginated, sortable, filterable, exportable table. That's the whole host component.

Signals from the start

I built this after Angular 17 shipped, so I went all-in on the signals API. No @Input(), no EventEmitter, no ChangeDetectorRef. Everything is input(), output(), computed(), effect().

I wasn't sure how it would feel at first but honestly it's made the component much easier to reason about. I've never once had to think about change detection. Would not go back.

The Windows `file:` reference trap

This one annoyed me more than it should have.

When developing a library locally you need the demo app to consume the built output. I used "ngx-mat-simple-table": "file:./dist/ngx-mat-simple-table" in the root package.json. On macOS this works fine. On Windows, npm install with a file: reference copies the files at install time — so running build:lib:watch updates dist/ but node_modules/ stays completely stale. I kept seeing old code after rebuilds and couldn't figure out why for longer than I'd like to admit.

The fix is tsconfig.json paths instead:

"paths": {
  "ngx-mat-simple-table": ["./dist/ngx-mat-simple-table"]
}

Angular's build system watches files resolved through paths, so incremental rebuilds are picked up immediately. Should have just done this from the start.

CDK drag-reorder was a puzzle

Column drag-reorder uses Angular CDK. My first attempt put cdkDropList and cdkDrag on the same <th> element. CDK silently reported previousContainer === container on every drop, so the column order never actually changed. Body cells stayed out of sync with headers. No error, just nothing happening.

The fix: <th> is the CdkDropList, a wrapper <div> inside it carries CdkDrag. Separate elements. Also — and this surprised me — Angular's @for block doesn't work here. CDK needs to traverse the view tree to find connected drop lists, and @for uses a different internal structure than *ngFor. Switching to *ngFor on the column blocks fixed it.

Don't install SheetJS without checking if it actually does what you need

I needed styled Excel headers. I installed SheetJS (xlsx), the most popular option. Spent a while getting it set up, wrote the header styling code, tested it — headers were completely plain. No error, styling just silently had no effect.

Turns out cell styles in SheetJS community edition are a Pro-only feature. It's in the docs if you look for it, but it's not exactly front and centre.

Switched to ExcelJS (MIT, actually free) and it worked immediately. The API is clean and it supports full cell styling. To match the exported header to the rendered grid I just read styles from the DOM at export time:

const el = hostEl.querySelector('th.mat-mdc-header-cell') as HTMLElement;
const cs = window.getComputedStyle(el);
const bg = this._cssColorToArgb(cs.backgroundColor); // → ARGB hex for ExcelJS
const bold = parseInt(cs.fontWeight) >= 600;

Whatever theme or custom CSS the host applies, the Excel header automatically matches it.

Export should export everything, not just what's on screen

The first version of export grabbed whatever rows were rendered — so if you were on page 3 of 10, you'd export 10 rows. Obviously wrong in hindsight.

Client-side mode was easy to fix: export MatTableDataSource.filteredData, which has all filtered rows regardless of page.

Server-side mode needed a different approach. The <st-export> directive accepts an allDataProvider callback — the host provides a function that fetches everything from the API without pagination params:

readonly getAllForExport = (): Promise<Task[]> => {
  return firstValueFrom(
    this._http.get<TasksResponse>('/api/tasks', { params: this.activeFilterParams() })
      .pipe(map(r => r.data))
  );
};

<st-export filename="tasks" [allDataProvider]="getAllForExport" />

Active filters are forwarded so the export reflects exactly what the user sees — just without the page limit.

Vercel 404 after deploy

After one release the demo started returning 404 on every route. Angular 17+'s esbuild builder outputs to dist/<project>/browser/ — Vercel was pointed at dist/<project>/ and finding no index.html.

Fixed with a vercel.json:

{
  "buildCommand": "npm run build:lib && npm install && npm run build",
  "outputDirectory": "dist/Demo-table/browser",
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

The rewrites rule matters too. Without it, refreshing any route other than / returns 404 because Vercel looks for a file at that path instead of letting Angular's router handle it.

Where it is now

npm: ngx-mat-simple-table
Demo: ng-simple-table.vercel.app
GitHub: github.com/xonaib/ng-simple-table

It has pagination, sorting, multi-select, dropdown filters, column chooser, drag-reorder, column resize, sticky columns, Excel export with full header styling, user settings persistence, and virtual scroll. Client-side and server-side data modes.

If you're building data-heavy Angular apps, hopefully it saves you some of the boilerplate.

What's new in v1.2

Since the original post the library has grown quite a bit. Here's what landed in v1.2:

Sticky columns — ColumnDef.sticky: 'left' | 'right' pins columns to either edge during horizontal scroll. Drag-reorder is automatically disabled for sticky columns so users can't accidentally break the layout.
Dark mode — all colour tokens alias Angular Material 3 system tokens, so flipping body { color-scheme: dark } adapts the entire table with zero extra CSS. Use the CSS light-dark() function for any custom cell colours and they adapt too.
cellClass callback — return a CSS class from (value, row) for conditional cell styling — colour-coded status badges, priority indicators — without needing a full custom template.
fillContainer mode — set TableConfig.fillContainer: true and the table stretches to fill its parent height. Toolbar and paginator stay pinned; only the rows scroll.
22 CSS custom properties — every visual surface now has a --st-* token covering header, borders, row backgrounds, hover, sticky cells, cell text, scrollbar, filter popup, and column chooser. Override any of them on the element or any ancestor.
State persistence fix — new columns added after a saved state are now correctly appended rather than silently dropped.

What's new in v1.3

v1.3 ships virtual scroll.

Pagination works, but some UIs just want to scroll. Flip one flag and the paginator disappears and CDK virtual scroll takes over — only the rows in the viewport are in the DOM.

Client-side is a one-liner config change:

<simple-table
  [dataSource]="allRows"
  [columns]="columns"
  [config]="{ virtual: true, virtualRowHeight: 48 }"
/>

Pass your full array. The component handles everything internally.

Server-side is where it gets more interesting. Instead of fetching everything upfront, the table emits a virtualRangeChange event as the user scrolls, telling you which rows are in view. You fetch just that window:

<simple-table
  [dataSource]="currentWindow"
  [columns]="columns"
  [config]="{ virtual: true, virtualRowHeight: 48 }"
  [virtualOffset]="windowStart"
  [totalLength]="totalRecords"
  (virtualRangeChange)="onRangeChange($event)"
/>

onRangeChange({ start, end }: VirtualRange) {
  this.windowStart = start;
  this.http.get(`/api/items?offset=${start}&limit=${end - start}`)
    .subscribe(data => this.currentWindow = data);
}

virtualOffset tells the table where in the full dataset your loaded window starts. totalLength sizes the scroll track correctly so the scrollbar reflects the real dataset. You never load more than what's on screen.

One thing that took longer than expected: CDK virtual scroll normally positions loaded content by applying transform: translateY() to the content wrapper. That creates a CSS stacking context, which breaks position: sticky on the table header — the header scrolls away with the content instead of staying fixed. The fix is to no-op that transform entirely and use margin-top instead. Same visual positioning, no stacking context, sticky headers stay sticky. Not obvious until you hit it.

DEV Community: Zonaib Bokhari

Ef-timelapse: a time-travel viewer for your EF Core schema published

Update: v0.2.0 adds an entity relationship visualizer

Two ways to look at schema history

Finding when something actually changed

It shows you the actual diff, not just a summary

Does it hold up on a real codebase?

What it deliberately doesn't do

Try it

ng-loom: a dependency graph for your Angular app, as a single HTML file

What it actually does

Why a static HTML file

What's there and what isn't

Try it

I built a form builder that lives inside your AI chat

Here's what it actually looks like

What it supports

The bit I find genuinely cool about this

How I built it

No install needed if you just want to try it

The webhook thing

Try it / grab the code

I got tired of copy-pasting the same table code, so I built a library

The core idea

Signals from the start

The Windows file: reference trap

CDK drag-reorder was a puzzle

Don't install SheetJS without checking if it actually does what you need

Export should export everything, not just what's on screen

Vercel 404 after deploy

Where it is now

What's new in v1.2

What's new in v1.3

The Windows `file:` reference trap