isValidationError

Type guard to distinguish Kizuna validation errors from custom 400 responses on the client.

Distinguish a Kizuna validation error from a route's own 400 body.

pnpm add kizunajs@beta

bun add kizunajs@beta

npm install kizunajs@beta

import { isValidationError } from 'kizunajs';
// also re-exported from @kizunajs/fetch

Parameters

isValidationError(body: unknown): body is ValidationError

`ValidationError` shape

An RFC 9457 Problem Details body with an errors extension:

interface ValidationError {
    type: string;
    title: string;
    status: number;
    detail: string;
    errors: Array<{
        code: ValidationIssueCode;
        path: string[];
        message: string;
    }>;
}

code is typed as ValidationIssueCode, so the built-in Zod codes are offered as autocomplete suggestions, while any custom string (e.g. one emitted via k.issue) is still assignable.

Common error codes: invalid_type, too_small, too_big, invalid_string_format, unrecognized_keys, not_multiple_of, custom. To emit your own machine-readable code from a .superRefine() check, see k.issue.

Example

When a route declares its own 400 response, the client sees a union of your type and ValidationError. Use isValidationError to distinguish them:

users.ts

import { isValidationError } from '@kizunajs/fetch';

const result = await client.users.createUser({
    body: {
        name: '',
        email: 'not-an-email',
    },
});

if (result.status === 400) {
    if (isValidationError(result.body)) {
        for (const error of result.body.errors) {
            console.log(error.code, error.path, error.message);
        }
    } else {
        console.error(result.body.detail);
    }
}

A route that declares no 400 of its own needs no guard: result.status === 400 already narrows to ValidationError.

See the Fetch client guide for more details.

Parameters

ValidationError shape

Example

On this page

`ValidationError` shape