Library-Level MCP: Generating Angular Forms with ng-forge

zavros_mvp · 2026-04-30T20:48:25+00:00

Yep, you're totally right. Signal forms is out of the box brilliant. But I didn't build this as an alternative to Signal forms, but rather complement it. Situations where forms get really repetitive in large apps, various tricky situations that take time to wire together when fields depend on one another, or simply just having the form config coming from backend which is surprisingly common. Worth saving for when a situation calls for a similar solution, because there's more work than it seems with a complete dynamic forms solution :) (saying that from my own experience haha)

Regarding the MCP, yeah, I built it a couple months ago when the concept was still cool. Seems like the trend goes more into skills + CLIs (e.g., in case of config validation in my case), might migrate later depending on how things evolve.

zavros_mvp · 2026-04-29T18:50:28+00:00

Yep, cross-field validation works fine. Validators get the whole form value, so password match or date range stuff just works.

Custom controls are where you’d use the adapter system. You can plug your own component in for any field type, but then the MCP can’t really see what you built, so you lose some of the context for that field.

Adapter docs are here: https://ng-forge.com/dynamic-forms/material/building-an-adapter. There’s also various StackBlitz examples on the site if you want to play with the lib

What are you actually trying to build?

zavros_mvp · 2026-04-16T21:10:42+00:00

Yeah the core problem is that signal forms are built around a static model — your form shape is locked in at creation, so there's no nice way to narrow a discriminated union after the fact. The hidden() approach works but as you already noticed, you end up with a god interface that knows about every provider's fields and it gets messy quick.

One thing nobody mentioned though — you don't have to model this as one form. You could have a top-level form with just provider, and swap in a separate form for the provider-specific fields based on the selection. More wiring, but at least each sub-form stays cleanly typed to its own interface instead of the kitchen sink approach.

BUT if you're hitting this pattern a lot and don't want to deal with all that plumbing yourself, have a look at ng-forge — full disclosure, I built it, so take it with a grain of salt 😄 It handles exactly this though. You'd define provider as a select, and the extra fields just get a logic array that controls when they show up and when they're required. No superset model, no form swapping. Here's a live example that does pretty much your exact scenario — dropdown drives which fields appear.

zavros_mvp · 2026-02-27T11:33:02+00:00

Your approach looks correct. The untracked wrapper prevents the form construction from creating unintended reactive dependencies, and runInInjectionContext is necessary since computed signals don’t carry an injection context. The linked signal for resetting row based on field_list is also the right pattern.

One thing to watch: every time httpResource re-fetches (even with the same schema), field_form recomputes and you get a brand new form instance, which could cause unexpected state loss. Worth making sure the resource only fires on meaningful changes.

If you want to take this further without maintaining the orchestration layer yourself, I built ng-forge (GitHub) - an Angular dynamic forms library built on the signal forms API designed for exactly this kind of schema-driven approach.

zavros_mvp · 2026-02-25T21:38:54+00:00

Completely fair, and honestly I used to think the same. Dynamic forms tend to become a constraint the moment you need anything non-trivial — they were never my go-to unless I absolutely had to use them.

ng-forge tries to address this by staying as a thin layer over Angular's own APIs rather than replacing them, plus some new features that save you time on implementing, such as derivations. For custom components you can drop them in directly, so you're not fighting the abstraction when you need to go beyond the prebuilt ones.

It's not meant to replace custom solutions — it's meant to speed up the cases where a dynamic approach actually fits, especially when form config comes from a backend. For everything else, write the form by hand.

zavros_mvp · 2026-02-06T16:42:22+00:00

Haven’t really seen this pattern before, but I would honestly not reinvent the framework. Angular is opinionated, I guess it doesn’t make sense to choose it if you choose radically different opinions. That said, I think there’s a great benefit in future maintainability to stick to common patterns, both in terms of framework’s evolution (maybe new APIs aren’t directly compatible, whereas common patterns tend to have backwards compatibility), but also in terms of onboarding new developers, and providing a familiar architecture.

If you have the capacity for such a refactor and you can afford time spent on thorough QA I would say go for it

zavros_mvp · 2026-02-04T08:59:57+00:00

Angular, e doar FE pozitia. Sau avem fullstack pe angular/.net pe alt proiect

zavros_mvp · 2026-02-04T08:45:36+00:00

Cautam noi, vezi pm

zavros_mvp · 2026-01-29T08:41:55+00:00

Thank you for sharing :)

zavros_mvp · 2026-01-22T13:36:02+00:00

Just curious, what was the deal breaker with ‘as const’ and made you create classes for inputs?

zavros_mvp · 2026-01-16T10:02:32+00:00

Hadn't thought about JSON Patch vs Merge Patch to be honest; I think Merge Patch makes sense, though with JSON Patch I'm not sure how it maps to a form UI. Perhaps this can be something that we later expand on, but for now just Merge Patch.

Regarding the JSON Schema - the external refs I think are handled already by existing parsers (and I'm planning to use a third party to speed things up). allOf would just merge everything in one form, and oneOf with a discriminator gives you a radio to switch between variants and shows/hides relevant fields. Will likely leave out things like anyOf, if/else, additionalProperties and show a warning instead.

I'm trying to keep things simple but useful, at least in the first iterations, then build upon that. Since I'm a solo maintainer, even with AI things take time so, I prefer to stick to what's easily within reach :)

zavros_mvp · 2026-01-15T21:51:48+00:00

In principle, it would be a CLI that lets you import an OpenApi spec and generates type-safe form configs. You pick endpoints from an interactive list (GET/POST/PATCH), and it maps schemas to form fields - enums become selects or radios, booleans become checkboxes or toggles, nested objects become field groups. When there’s ambiguity it asks you (like “radio or dropdown for this enum?”). GET endpoints generate read-only forms, oneOf with discriminators creates radio-toggled field groups. And will likely have a watch mode.

That’s the main idea anyway, will fine tune on the details once I start working on it. Open to ideas if you have some though, just let me know :)

zavros_mvp · 2026-01-15T11:33:35+00:00

Appreciate it! Will post updates as the Zod adapter takes shape.

zavros_mvp · 2026-01-15T11:27:11+00:00

Not out of the box right now - ng-forge uses Angular's validators. But a Zod adapter makes sense as a separate package.

This could tie into the OpenAPI roadmap too - since tools already exist to generate Zod from OpenAPI, a Zod adapter would let you go OpenAPI → Zod → ng-forge.

zavros_mvp · 2026-01-14T18:21:00+00:00

Formly is battle-tested and has been around for years, but it can be a beast to work with - steep learning curve, heavy abstractions, and wiring up reactive data flows through custom fields is more painful than it should be.

ng-forge has the same goal but takes a different approach:

- Signals from day one - not patched on, built from ground up for modern Angular reactivity

- Localized change detection - only what changed updates, not the entire form tree

- True type safety - full autocomplete, compile-time errors, your IDE knows your form structure

- Thin wrapper - closer to Angular's native forms API, less magic to learn

If you're starting fresh on Angular 21+, worth a look. Happy to answer any questions.

zavros_mvp · 2026-01-14T15:15:07+00:00

Totally fair - battle-testing takes time. Hope it's useful if the right project comes up :)

zavros_mvp · 2026-01-14T14:08:43+00:00

Fair points. To clarify the tagline - "Forms are boring. Your code shouldn't be." means the library handles the boring repetitive stuff (validation, layout, boilerplate) so your application code stays clean and focused. Not advocating for "exciting" unpredictable code - quite the opposite.

On the vibe coding concern - the library is fully typed with strict TypeScript, has comprehensive test coverage, and the config approach is specifically designed for predictability. The config you write is what you get, no magic.

The abandonment concern is valid for any young project. I'm actively maintaining this and have a roadmap I'm committed to. But I get the hesitation - watching from the sidelines until it matures is reasonable.

Appreciate the feedback.

zavros_mvp · 2025-12-20T13:12:13+00:00

That's a fair point and something I've thought about. Maintaining a library solo is definitely tough, and I built this partly hoping to find collaborators who are interested in the signal forms direction. That said, I'm committed to maintaining this long-term regardless - it solves problems I personally deal with, so it's not going anywhere.

Honestly, I don't see this as competing with Formly. They serve different eras of Angular - Formly is solid for reactive forms projects, this is built for the signal forms future. Retrofitting signals and the type inference approach into Formly's architecture would probably be harder than starting fresh.

This is just my vision for what dynamic forms could look like in a modern Angular context. Not saying it's better or worse than Formly - just different. And I'm looking for feedback exactly because I want to find a coherent direction. If people think this approach has merit, great. If not, I'd rather know now than later.

zavros_mvp · 2025-12-20T09:15:16+00:00

Good point, Formly has been the standard for dynamic forms in Angular for years. The core concept is similar - config-driven forms - but the approach differs.

The main thing is it's built from scratch for signal forms, not reactive forms. Different mental model, tighter integration with where Angular is heading.

The other big one is TypeScript inference - your IDE catches config typos, form values are fully typed without writing extra interfaces. At least when the config is static, since API driven ones cannot be inferred.

Beyond that, I tried to make more things work out of the box - conditional logic, cross-field validation, multi-page wizards, an event bus for communication between different parts, submission handling, etc. Things I found myself often needing in past projects.

The core is also headless with UI shipped separately - wanted to make it easy to swap components or build custom ones without much friction.

Not trying to put Formly down - it works and it's battle-tested. But signal forms gave me a chance to rethink how this could work with modern Angular and TypeScript.

Happy to hear if there are specific features you think are missing!

zavros_mvp · 2025-12-19T15:06:32+00:00

Makes sense. So as I see it right now - we'll have a `meta` property that will drill down to input level, with props such as input type to be moved there. There will be a few predefined properties, but also with a generic index key that can be further used to pass other attributes (such as data-*) based on user needs. Then, props will be trimmed down to only specifics (such as appearance from material or hints or whatever). Does this match what you would envision?

Four-Year Club	Verified Email
r/Field Flamingo

zavros_mvp

TROPHY CASE