svelte-jsonschema-form

The @sjsf/sveltekit package provides integration capabilities for svelte-jsonschema-form within SvelteKit applications. It supports two primary patterns for handling form data and logic:

1. Form Actions: Use SvelteKit's native Form Actions to handle form submissions.
2. Remote Functions: Use remote functions for more complex or decoupled logic.

Refer to the official documentation for detailed implementation guides on these patterns.

The UI Schema is a configuration object that follows the tree structure of your JSON Schema. It allows you to customize the appearance and behavior of form fields without modifying the underlying data schema.

Key capabilities include:

• Overriding UI components (widgets).
• Providing custom UI options (e.g., labels, ordering, array behaviors).
• Defining specific UI schemas for complex structures like oneOf, anyOf, items (arrays), and additionalProperties (objects).
• Using $ref to point to shared definitions in ui:definitions.

The project is organized into a hierarchical structure of packages and tools. The top-level hierarchy flows from the root through the code generation and composition layers, eventually reaching the playground and builder environments:

root > codegen > composer > playground > builder

The library natively supports JSON Schema Draft-07 and the discriminator.propertyName keyword.

To use other formats like Draft 2020-12, you must use converters such as @sjsf/form/converters/draft-2020-12 in combination with adapters like @sjsf/zod4-validator/classic, @sjsf/zod4-validator/mini, or @sjsf/valibot-validator.

Some theme packages use specific naming conventions based on the major version of their underlying dependencies to maintain clarity during transitions:

• Flowbite Themes: @sjsf/flowbite3-theme is named after the major version of the flowbite package (even though its primary dependency is flowbite-svelte).
• Shadcn Themes: @sjsf/shadcn4-theme is named after the major version of tailwindcss.

When using native-file or native-files fields, uploaded files are represented directly as File objects.

Pros: No encoding/decoding overhead and metadata is preserved. Cons: Files cannot be provided from the server and may cause compatibility issues with JSON-oriented tools like JSON Schema validators.

Requirement: You must set enctype="multipart/form-data" on your form.

The project uses two distinct npm scopes to signal the stability and versioning behavior of its packages:

@sjsf-lab (Unstable/Experimental)

• Purpose: Used for packages that are not yet stabilized.
• Versioning: Packages are versioned independently.
• Compatibility: The major version of a @sjsf-lab package matches the compatible version of @sjsf/form. Note that breaking changes may occur between minor versions.

@sjsf (Stable)

• Purpose: Used for stable, production-ready packages.
• Versioning: Packages are versioned in sync. Packages sharing the same version number are guaranteed to be compatible with each other.
• Deprecation: When a stable package is deprecated (e.g., replaced by a newer version), it remains in the @sjsf scope but switches to independent versioning.

To avoid the overhead of Data URLs and the limitations of native File objects, you can preload files into a storage backend immediately upon selection. In this pattern, the form value only stores a lightweight file identifier (ID) instead of the file data itself.

Advantages:

• Smaller payloads (no Base64 overhead).
• Files can be validated or processed on the server before the final form submission.
• Files can be provided from the server.

Because the cfworker validator does not natively support undefined, you can use a valueToJSON function to normalize values. This implementation converts undefined or null to null and performs a deep clone of objects to ensure JSON compatibility.

const valueToJSON = (v: FormValue) =>
  v === undefined || v === null
    ? null
    : typeof v === "object"
      ? JSON.parse(JSON.stringify(v))
      : v;