Launched this week
NGX View Builder (Beta)
Build Angular views visually, ship them as JSON
10 followers
Build Angular views visually, ship them as JSON
10 followers
NGX View Builder is a visual, drag-and-drop form and view builder for Angular. Design forms, dashboards, and data tables as JSON in a low-code builder, and render them natively with a full Angular runtime.
Hi everyone! 🙂
I started building NGX View Builder because one of the projects at my company needed dynamic, JSON-driven forms with drag-and-drop editing. The original idea was to build an in-house form builder, but once we estimated the scope, we realized it was much bigger than expected. The company chose an existing solution instead.
That made me wonder could I build something like this myself?
I started on January 21 2024, working on it in my free time after work, on weekends, and during holidays. Along the way I rewrote the project three times. The first two versions were mostly R&D, helping me figure out the architecture and what a builder like this actually needs.
Using the commercial builder at work every day also showed me what was missing, and many of those ideas ended up in NGX View Builder.
The goal was never just another form builder. I wanted something that integrates directly into an Angular application, stores everything as JSON in your own database, and is designed to be extended with custom elements, plugins, themes, REST integrations, and business logic.
The most challenging part was building the expression system, especially making calculations work correctly across dynamic tables and panels with all their state changes and dependencies.
After about two and a half years of work, this is the result. I'd genuinely love to hear what Angular developers think. What would you want to see in a tool like this?
🎯 NGX View Builder
Visual development tools are getting crowded.
What's the one workflow where you think developers become dramatically faster instead of just writing less code?
@aryan787544 Fair question, and I don't think the answer is writing less code.
The part that actually changes is what happens after the first version ships. On the frontend you write this once:
<ngx-view-builder-runtime [pageJson]="pageJson()" [dataJson]="dataJson()" />
That's the whole integration. From there the view is a JSON document, not code, so an analyst takes over in the builder and does the rest by the docs add a field, make it conditional, add a language, change validation, restructure the layout. No branch, no PR, no QA queue, no release. The change is live the same afternoon, because nothing was compiled into the bundle in the first place.
This isn't a hypothetical for me. At the company I currently work at, the analysts already run a module like this day to day, they build and change the screens themselves and developers only get involved when something genuinely new is needed. That is where the whole idea came from, I wanted that workflow as a proper Angular library instead of something glued into one internal system.
That's where it stops being a percentage. Hand coding a form the first time is maybe a day, that was never the expensive part. The cost is the forty change requests over the next two years, and normally every one of them needs a developer and a deploy. Here they need an analyst and a save. And since views are just JSON, you still version them, diff them in review and roll them back like any other artifact.
@ngx_vb That's the part I find most interesting. It sounds like the product isn't replacing developers so much as changing who owns change after the first release. I'll be curious whether teams eventually buy NGX View Builder because it's a faster UI builder, or because it fundamentally changes the relationship between engineering and the business. Those feel like two very different categories.
@aryan787544 I can't predict how different companies will adapt or what their business models will look like, but I don't see this as replacing developers. Developers will still be needed when businesses require additional functionality.
The idea is that developers can focus on creating custom components, tabs, expression functions, integrations, parameters, and other building blocks, while business teams can use those capabilities to create and adjust solutions faster.
In some cases, a business module might change completely over time, and that's where having a flexible builder can help.
@ngx_vb Really enjoyed this discussion. The distinction between making developers faster versus changing who can safely own product changes feels like the more important story here.
I've got a couple of thoughts on how that positioning could become even sharper as this category evolves. If you're open to it, what's the best email to send them to?
Finally an Angular form builder that doesn't feel like a toy. The JSON-to-native-render approach is basically the right call for teams already deep in Angular, and the drag-and-drop actually respects your component model instead of forcing some half-broken abstraction on top of it.
@habibepeksen Thank you, Habibe Peksen.
The idea behind this tool was to create a builder for analysts or other users who work with clients and can create the interface directly during discussions. Developers can then extend it, customize it, and adapt it according to specific needs.
This saves a lot of time compared to creating designs in Figma or other tools and then having to convert those designs into Angular code, which is a time consuming process.
Tried it out on a simple dashboard and the drag-and-drop felt surprisingly snappy. Love that the output is just JSON, makes it easy to tweak things by hand when needed.
@metehanhgei Thank you for your comment, Metehan.
The drag-and-drop mechanism took a lot of time to develop, but it was worth the effort. I still think there are areas where it can be improved, and the quality will continue to get better over time.
Regarding JSON, yes, this is one of the most important aspects of the tool. It allows you to modify and adjust views that are already running in production in real time, without the need for redeployment. By changing the JSON, everything updates immediately.
Of course, the real value also depends on how this tool will be used and in which scenarios.
A solid step up from hand-coding reactive forms. One thing that would make this stick for me is a built-in validation rule library with visual error messages, so non-developers can actually ship polished forms instead of just basic inputs.
@yazj2rv Thanks, that's a fair hit. The types today are pretty generic: required, minLength, maxLength, min, max, pattern, email, strictOptions and custom. There's a visual condition builder behind custom and every rule has its own error message, but anything beyond the basics still ends up as a regex in pattern, which is exactly where a non-developer gives up.
Two things I want to do. First, let developers register their own rule types so they show up in that same dropdown. Most real world rules are country specific, phone numbers, tax IDs, personal codes, postal codes and bank accounts all look different in every market, so shipping one fixed set would be wrong for most people. You register something like ltPersonalCode once, with its own default message, and from then on creators just pick it from the list like any built in rule. Second, more built in rules for the genuinely universal stuff: URL, password strength, must match another field, date in the past or future, minimum age, file size and type.
One question so I start with the right one. When you say visual error messages, do you mean how the errors look, or writing the message without doing it rule by rule?
Dragging components together and seeing the JSON update live felt pretty slick. Rendering them as real Angular components without extra wrappers is a nice touch.
@yaarayasp3xo Thanks for the comment, Yaşar Ayas!
Yes, you're right whatever you drag onto the canvas is already an Angular component, the exact same one that gets rendered at runtime.
And yes, the JSON updates on every change. There's also an event hook in the code where you can decide how to handle saving autosave to your own backend, persist the JSON locally, or just keep it in a local variable and save it manually when you hit the save button.