form-codegen

Generate schema-driven forms with shared validation across WASM and backend services.

1|Updated Dec 2, 2023
One-click install
npx skills add https://github.com/tinywasm/devflow --skill form-codegen
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: form-codegen
Source: https://github.com/tinywasm/devflow/tree/main/skills/form-codegen
Command: npx skills add https://github.com/tinywasm/devflow --skill form-codegen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Form creation and validation are often duplicated across frontend WASM and backend server code, leading to drift, inconsistent UX, and maintenance overhead.

Core Features & Use Cases

  • Schema-driven form creation via form.New(parentID, &struct) to generate consistent, UI-linked validation for both WASM frontend and server backend.
  • Shared validation logic across fmt, dom, form, form/input, json, and orm to ensure uniform behavior.
  • Cross-library coordination that keeps widget defaults, input widgets, and data models in sync across the stack.

Quick Start

Define a Go struct annotated with // ormc:form and instantiate it with form.New to generate a shared form across frontend and backend.

Frequently Asked Questions about form-codegen

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I share form validation logic between a WASM frontend and backend server?

Generate schema-driven forms by calling `form.New(parentID, &struct)` with an annotated Go struct. This creates consistent widgets and validation flows across tinywasm dom, form, and orm libraries.

How do I generate schema-driven forms for WASM frontend applications?

Assign widgets using directive-based annotations on your Go struct fields. This approach establishes Go type defaults and coordinates cross-library validation flow between frontend and backend.

Can I use Go type defaults to assign form input widgets across frontend and backend?

It standardizes validation rules across fmt, dom, form, form/input, json, and orm libraries. This prevents drift and maintenance overhead caused by duplicating form creation logic across frontend and backend.

Why does my form validation logic drift between frontend and backend code?

No extra dependencies are required. It relies on the existing tinywasm/dom, form, and orm libraries to support directive-based widget assignment and cross-library validation flow.

Do I need external dependencies to maintain cross-library form validation?

It coordinates cross-library validation flow across fmt, dom, form, form/input, json, and orm to keep widget defaults, input widgets, and data models synchronized across the stack.