Self-Saving Forms

A form is only as useful as its ability to save. It sounds obvious, but the wiring between a form and the data it manages has historically been one of the most repetitive pieces of any application. You define the fields. Then you wire up the save action. Then the update action. Then delete. Then validation. Then error handling. Then success feedback. By the time a form is fully functional, you've written far more code than the form itself required.

Self-saving forms eliminate that overhead entirely.

One Definition, Full Lifecycle

When you define a form component in Swifty, you specify the data object it operates on and the fields it should display. That's it. The form handles the rest:

• Create mode: Opens with empty fields; saves a new record on submit
• Edit mode: Pre-loads existing data; updates the record on submit
• Delete: Built-in delete action with confirmation, no wiring needed
• Validation: Field-level validation runs before any save operation
• Error display: Validation errors appear inline next to the relevant field
• Success feedback: Confirmation notification after successful save or delete

All of this happens automatically, derived from the form definition and the object type it targets.

Context-Aware Behavior

Forms detect whether they're in create or edit mode based on context. If a record ID is available — from the URL, from a parent component, or from a data source — the form loads and saves that record. If no ID is present, the form creates a new one on submit.

This means the same form definition works for both create and edit. You don't need two separate forms. The builder shows a single form component; the runtime handles the distinction.

Pre-Fill and Defaults

Self-saving forms respect pre-fill configurations. Default field values, values inherited from parent records, and query-parameter pre-fills all work without additional setup. When a user opens a create form linked from a specific project, the project field is pre-populated automatically.

Validation That Matches Your Data Model

Validation rules come from the field definitions, not from the form configuration. Required fields, valid option values, format constraints — all of them are enforced at the form level before any save is attempted. If a field is marked required in the object definition, the form won't submit without a value, regardless of which form component is used.

Less to Build, More to Trust

The practical result is that adding a new form to your application takes minutes. Define the object, create the form, select the fields — done. The form is immediately functional: it saves, updates, validates, and handles errors without any additional configuration.

That's time reclaimed for the work that actually differentiates your application.