Form Portability Hindered by Callbacks, Not Just JSON

The Limits of JSON in Form Definition

Most form libraries manage form state within a single application. They handle value tracking, validation execution, error display, and payload generation. This internal focus works fine as long as the form remains confined to its original environment. However, the moment a form needs to exist outside this boundary – perhaps rendered from a backend, generated by a visual builder, shared across multiple applications, or requiring server-side validation of client-side logic – its limitations become apparent. At this point, the form transcends mere component state; it becomes a contract. Many existing form abstractions fail to cross this critical boundary.

The illusion of portability often stems from representing the form structure as JSON. While JSON can describe the fields, their types, and basic properties, it falls short of capturing the dynamic behaviors and business logic embedded within a form. Validation rules, conditional logic (showing/hiding fields based on other inputs), dynamic data collections (like dropdown options fetched from an API), and submission semantics (how data is processed or where it's sent) are often implemented using JavaScript callbacks or functions. These are inherently tied to the execution environment of the application where the form was built. When you serialize a form with such callbacks into JSON, you're essentially sending an empty shell; the intelligence and behavior are lost because functions cannot be directly serialized into standard JSON.

Consider a simple example: a form field whose options are populated by an asynchronous API call. In a typical library, this might be handled by a callback function passed to the `options` property of a field definition. When this definition is sent as JSON to another application or the backend, the `options` property might appear as `null` or an empty array, because the callback function itself cannot be represented. The same applies to validation. A custom validator that checks a complex business rule, or a conditional logic that shows a field only if another field has a specific value, are often implemented as functions. These functions are part of the application's code, not data that can be easily exported and imported.

Callbacks as the Portability Bottleneck

The core issue is that callbacks represent executable code, not declarative data. Portability implies that a form definition should be self-contained or have clearly defined, external dependencies that can be resolved in any environment. Callbacks, by their nature, are context-dependent. They rely on the surrounding JavaScript runtime, scope, and available APIs. When a form definition needs to travel – from a frontend component to a backend service for validation, or from one microservice to another – these callbacks break. The receiving environment doesn't know how to execute them, or they might refer to variables or services that don't exist there.

This problem extends beyond simple form field values. It impacts the entire user experience and data integrity. If a form's conditional logic is hardcoded in callbacks, the backend cannot replicate that logic for server-side validation. This forces developers to either duplicate the logic in two separate places (frontend and backend), increasing maintenance overhead and the risk of divergence, or to forgo server-side validation for those dynamic aspects, compromising security and data accuracy. Similarly, if a form relies on a visual builder that generates its structure, and that structure includes callbacks for dynamic behavior, the builder cannot reliably export a complete, functional definition that can be used elsewhere without those callbacks being re-implemented manually.

Modyra, for instance, tackles this by abstracting away from direct callbacks. Instead of passing a JavaScript function for conditional logic, it defines rules in a declarative, data-driven manner. This might involve specifying conditions like 'show field X if field Y equals Z' using a structured format that can be serialized and understood by any environment. Similarly, for data collections, it might use references to named data sources that can be independently resolved. This approach treats the form definition as a contract that can be interpreted and executed consistently across different systems, whether it's the browser, a server, or even a low-code platform.