A schema-driven form renderer is a small runtime, not a loop that maps field names to inputs. It compiles a versioned data contract and presentation metadata into a safe field projection, trusted widgets, canonical values, and validation results.
Hard-coded forms are often the right choice. They are easy to read, tune, and test. A schema-driven renderer earns its complexity when many forms share rules, fields change without a full client release, several products render the same contract, or saved drafts must survive schema evolution.
The central design move is separation. A data schema defines allowed values and relationships. A UI schema describes order, grouping, help text, and requested widgets. Runtime context supplies locale, permissions, and feature availability. Canonical values remain independent of the mounted controls. The renderer derives a visible, enabled, required field projection from those inputs.
Start with the product boundary
Clarify who authors definitions, how they are reviewed, whether the client can receive new definitions without a deploy, and how long drafts live. Ask whether forms contain regulated data, remote option searches, custom controls, conditional sections, server validation, or multiple locales.
For this interview, assume hundreds of possible fields, fewer than eighty visible at once, conditional dependencies, remote options, authenticated drafts, SSR, and a small set of approved custom widgets. Definitions are produced by a trusted product service, but every downloaded value is still parsed as data. A no-code form builder, multi-step workflow engine, and arbitrary rules language are outside scope.
The public interview prompt
Design a schema-driven form renderer. Explain:
- the data schema, UI schema, runtime context, and versioned definition bundle;
- compilation, dependency indexing, conditional projection, and cycle detection;
- canonical typed values, defaults, hidden-field policy, and serialization;
- trusted widget resolution, adapters, native semantics, and progressive enhancement;
- synchronous, asynchronous, cross-field, client, and server validation;
- drafts, schema upgrades, migrations, reconfirmation, and unsupported versions;
- SSR, hydration, accessibility, internationalization, privacy, and security;
- performance, observability, testing, rollout, and failure containment;
- simpler alternatives and an interview-depth rubric.
What the premium solution covers
The complete solution builds the definition boundary, compiler, dependency graph, pure field projection, canonical value adapters, widget capability registry, validation issue model, revisioned async checks, hidden-value policy, migration ladder, server command, and production rollout plan.
Original media follows one dependency change through projection and stale-result rejection, maps the bundle-to-payload pipeline, audits the widget contract, and separates automatic migrations from changes that require confirmation. Two deterministic labs let you inspect field projection and widget resolution directly.