Vestjs Documentation

website·Indexed 33 days ago

https://vestjs.dev/

Searchable website documentation for Vestjs from https://vestjs.dev/.

Tokens
46.8K
Snippets
255
Records
327
Agent score
69%

What's inside Vestjs Documentation

  1. Vest integration compatibility overview

    Vest provides verified integrations across several categories to ensure runtime and type safety. Most current integrations utilize the standard-schema mechanism for interoperability. Verified integrations include:

    • Form State: TanStack Form
    • Servers & APIs: Hono (via @hono/standard-validator), tRPC
    • Routers: TanStack Router
    • Configuration: T3 Env
    • Specifications: Standard Schema
  2. Understand the role of Vest vs Schema Validators and Form Managers

    Vest is designed for stateful and stateless validation workflows, specifically handling how validation state evolves as a user interacts with a form. It differs from other tools in the following ways:

    • Form Managers (e.g., React Hook Form, Formik): Own values, registration, events, and submission. Vest does not store values or register inputs.
    • Schema Validators (e.g., Zod, Valibot, Enforce): Focus on structural validation, transformation, and parsing of a complete payload (boundary validation). Vest focuses on the interactive workflow (e.g., validating one field at a time, handling async race conditions, and conditional fields).
  3. Understand Vest's stateful validation behavior

    Vest suites maintain validation state between runs. When a focused run is performed (e.g., using suite.only('fieldName').run()), Vest updates only the specified fields and merges these results with the existing state of other fields. This allows isValid() to provide a complete validation status of the entire suite even when only a subset of fields was recently validated. Additionally, Vest prevents 'lagging' async tests by ignoring stale results if a newer test has already started.
  4. Prevent race conditions in async validation

    Vest has built-in race condition handling. If multiple async validations are triggered for the same field (e.g., during rapid typing), Vest automatically discards stale results and only processes the result from the most recent validation call. No additional configuration is required.
    // Even if the first call ('A') finishes after the last call ('ABC'),
    // Vest ignores the 'A' result and uses 'ABC'.
    suite.run({ username: 'A' });
    suite.run({ username: 'AB' });
    suite.run({ username: 'ABC' });
  5. Prevent double validation using State Serialization in SSR

    In SSR frameworks (Next.js, Remix, SvelteKit), running validation on the server and then re-running it on the client causes 'Double Validation'. Vest 6 solves this by allowing you to serialize the state of a suite on the server and inject (hydrate) it into the client-side suite. This ensures the client knows which tests passed, are pending, or were skipped without re-executing the logic.
  6. Determine when to use Vest for validation

    Vest is specifically designed for complex validation scenarios including:

    • Async checks (e.g., username availability, coupon codes).
    • Multi-step wizards or onboarding flows.
    • Fields with inter-dependencies.
    • Optional or conditional sections.
    • Dynamic lists of items.
    • Requirements for pending states, warnings, and progressive completion.
    • Validation shared between the browser and server.

    For simple one-time API payload parsing, an Enforce schema's .parse() method may be sufficient instead of a full Vest suite.

  7. Understand and use Data Parsers in Vest

    Data parsers transform values as they pass through an enforce chain by coercing them into a new form (e.g., trimming whitespace, converting types). Parsers are only available on lazy chains started with a type rule (like enforce.isString(), enforce.isNumber(), or enforce.isArray()) and are not available on eager enforce(value) chains.
  8. Understand the difference between skip and skipGroup in Vest.js

    When using suite.focus(), the distinction between skip and skipGroup depends on whether you are targeting individual fields or entire validation sections:

    • skip: Excludes tests by field name. Use this when you want to determine which specific field(s) should not run, regardless of their nesting level.
    • skipGroup: Excludes tests by group name. Use this when you want to determine which validation section (group) should not run, regardless of the field names inside that group.
  9. Integrate Vest validation with TanStack Form

    In this integration, TanStack Form manages the field state, while a Vest suite (owned by the instance) provides focused change validation and Standard Schema submission validation. This setup supports focused execution, input inference, multiple issues per field, nested paths, retained state, and synchronous execution.
  10. Implement a production registration flow with Vest and React Hook Form

    This architecture separates concerns into three layers: the form layer (inputs), the schema (boundary), and Vest (validation evolution). Key features of this implementation include:

    • Async Validation: Race-safe username availability checks.
    • Dependent Fields: Password confirmation linked to password changes.
    • Conditional Logic: Business accounts revealing a company section.
    • Non-blocking Feedback: Password strength implemented as a warning rather than an error.
    • Server-side Validation: Stateless Vest runs on the server to ensure request isolation.
  11. Integrate Vest with Standard Schema

    Standard Schema allows validation consumers to invoke a Vest suite or an Enforce schema through a shared interface. This integration supports full-payload validation, including asynchronous checks, input/output inference, nested paths, and transformed output. Note that this integration runs complete validation and does not support Vest's native focused execution, retained state, warnings, groups, or race coordination.
  12. Use Vest alongside external schema libraries like Zod

    Vest can coexist with other schema libraries. In this architecture, Vest handles the interactive validation logic (user feedback), while the external library (e.g., Zod) handles the final data contract parsing at the boundary before submission.
    const result = await registrationSuite.run(values);
    
    if (result.isValid()) {
      // Use Zod or another library to parse the final payload
      const payload = registrationSchema.parse(values);
      await api.register(payload);
    }