How Tungsten fits together

A portable schema describes the form. Core decides what it means. JavaScript connects it to your application and your interface.

Three inputs, one form

<Tungsten
  schema={schema}             // Structure, validation, rules, source references
  config={config}             // API transport and translation catalog configuration
  dataSources={dataSources}   // Named requests and response extraction/validation
  initialValues={draft}       // Meaningful values, not renderer state
  language="en"              // Presentation language for this instance
  onStateChange={inspect}     // Completed evaluations, valid or invalid
  onSubmit={save}             // Validated values after uploads
/>

Keep these responsibilities separate. A schema may be saved, exported, or authored in the editor without embedding credentials, JavaScript functions, or browser File objects.

Who owns what?

Part	Responsibility
Rust / WASM core	Compile schemas, normalize values, validate fields and references, evaluate rules, track source readiness, maintain repeater identities.
JavaScript API layer	Worker lifecycle and command order, network requests, cancellation, response extraction, upload bytes, synchronized state.
React host	Render the schema/state, forward user edits, manage submit lifecycle, deliver callbacks.
Design renderers	Controls, accessibility, navigation, focus, loading/retry controls, layout, and localized display text.
Your application	Authentication, endpoints, draft persistence, submission, storage, and deployment.

Sprout scope

Tungsten Sprout supplies the React integration with Tungsten, Bootstrap and Material designs. It includes basic fields, dates/times, files, async bindings, behavior rules, groups, nested repeaters, localization, and the visual editor. Angular remains deferred.

This guide describes the supported behavior, configuration, and integration contracts of the package version shown above.

Integration contracts

Use the Schema, Configuration, Core lifecycle, and Data sources chapters together when checking an implementation. Their constraints, state boundaries, ordering, and failure behavior describe what a host should observe. Registry-backed field and renderer tables reflect the installed core rather than a second hardcoded catalog.