dimaspanduOverview
A form system that adapts to each builder configuration.
I built a form system that adapts to different website builder configurations while keeping validation and UX consistent.
The same engine serves multiple templates, so each builder gets behavior tuned to its needs without forking the codebase.
The problem
Most form libraries assume a static schema.
Website builders need dynamic forms that change based on user selections, but most form libraries assume static schemas.
- Conditional fields and visibility rules don't fit a fixed, hand-written form structure.
- Validation logic is duplicated per template instead of being defined once and reused.
Approach
Separate schema from rendering.
I designed a field registry with conditional visibility, custom validators, and a unified submission pipeline.
Defining fields as data let the same form behave differently per template while sharing one rendering and validation core.
Solution
A reusable form engine driven by schema.
The solution is a reusable form engine that separates schema from rendering, allowing the same form to behave differently per template.
Builders declare fields and rules; the engine handles display, validation, and submission consistently.
Implementation
Vanilla JavaScript with a custom event system.
The engine was implemented in vanilla JavaScript with a custom event system, schema-driven rendering, and integration with backend form handlers.
Core
Vanilla JavaScript with a custom field registry and event system.
Rendering
Schema-driven rendering with conditional visibility and validators.
Backend
Integrated with backend form handlers for unified submission.
Results
What changed.
The engine reduced form implementation time by roughly 60% across multiple builder templates.
Links