Coder Legion - Recent posts tagged validation

Zod vs Yup in 2026: Which Validation Library Should You Use?

Sat, 22 Aug 2026 04:00:34 +0000

You've got a signup form. Email, password, maybe a checkbox for terms and conditions. Simple, right? Then someone submits email: 123 and your API route crashes with a cryptic error three files deep, because nothing ever checked that the data coming in actually matched what your code expected.

That's the exact gap schema validation libraries fill — and if you've searched for one, you've almost certainly landed on two names: Zod and Yup. Both let you describe the shape of your data once and validate real values against it. Both work great with React Hook Form. Both have been around long enough to be genuinely production-tested.

But they're not interchangeable, and picking the wrong one for your setup means either fighting TypeScript for months or hand-writing types you shouldn't have to. By the end of this guide, you'll know exactly how Zod and Yup differ, see real code for both, and know which one actually fits your project — not just which one has more GitHub stars.

Quick Answer

Choose Zod if you're using TypeScript and want your schema to be your type — no writing an interface separately and hoping it stays in sync.
Choose Yup if you're maintaining an existing Formik-based codebase, or your team is more comfortable with its .shape() API and mature async validation methods.

For any brand-new TypeScript project in 2026, Zod is the safer long-term default — it's what most modern tools (React Hook Form, tRPC, Next.js Server Action patterns) assume you're using. Now let's get into why.

What Is Schema Validation, Exactly?

Before comparing the two, a quick beginner-friendly definition: a schema is just a description of what your data should look like — "this field is a string," "this field is a number between 1 and 100," "this field is a valid email." A validation library takes that schema and checks real, incoming data (a form submission, an API request body) against it, telling you exactly what's wrong if it doesn't match.

Without one, you end up writing manual checks like this everywhere:

if (typeof data.email !== "string" || !data.email.includes("@")) {
  throw new Error("Invalid email");
}

Multiply that across every field, every form, every API route, and it gets messy fast — inconsistent error messages, duplicated logic, and no single source of truth for what "valid" even means. Zod and Yup both solve this by letting you define the rules once and reuse them everywhere.

Zod: TypeScript-First Validation

Zod was built specifically for TypeScript projects. Its core idea: you write one schema, and Zod derives both the runtime validator and the TypeScript type from it — there's no second place to keep in sync.

Installing Zod

npm install zod

A Basic Zod Schema

// lib/validators/user-schema.ts
import { z } from "zod";

export const userSchema = z.object({
  name: z.string().min(2, "Name must be at least 2 characters"),
  email: z.email("Please enter a valid email address"),
  age: z.number().int().positive().optional(),
  website: z.url().optional(),
});

// The type is derived directly from the schema — never written twice
export type User = z.infer<typeof userSchema>;

What's happening here: z.object({...}) describes the shape. z.email() and z.url() are Zod's built-in format validators (as of Zod v4, these live as top-level helpers rather than chained .email() string methods, though the chained form still works). z.infer<typeof userSchema> pulls a real TypeScript type straight out of the schema — if you add a field to the schema, the User type updates automatically, with zero manual work.

💡 Tip: This is Zod's single biggest selling point. You will never end up with a TypeScript interface that's quietly out of sync with your actual validation rules, because there's only one definition.

Validating Data with Zod

// Somewhere handling a form submission or API request
const result = userSchema.safeParse({
  name: "Ali",
  email: "not-an-email",
});

if (!result.success) {
  console.log(result.error.flatten().fieldErrors);
  // { email: ["Please enter a valid email address"] }
} else {
  // result.data is fully typed as `User`
  console.log(result.data.name);
}

What's happening here: safeParse() never throws — it returns a { success: true, data } or { success: false, error } object, so you don't need a try/catch block for normal validation flow. error.flatten().fieldErrors gives you a clean, per-field map of error messages, perfect for showing next to form inputs.

⚠️ Common Mistake: Using .parse() instead of .safeParse() in a code path where invalid data is expected (like a form submission). .parse() throws on failure, which means you need a try/catch everywhere — .safeParse() is almost always the better default for user input.

Zod in a Next.js Server Action

// actions/create-user.ts
"use server";

import { userSchema } from "@/lib/validators/user-schema";

export async function createUser(prevState: unknown, formData: FormData) {
  const result = userSchema.safeParse({
    name: formData.get("name"),
    email: formData.get("email"),
  });

  if (!result.success) {
    return { errors: result.error.flatten().fieldErrors };
  }

  // result.data is typed and safe to use here
  // await db.user.create({ data: result.data });

  return { success: true };
}

This is the exact pattern you'll see across most modern Next.js codebases — validate raw FormData on the server, never trust the client, and let the schema do the type narrowing for you.

Yup: The Established Forms Favorite

Yup predates the current TypeScript-first wave of tooling. It grew up alongside Formik and is still deeply embedded in a lot of React form codebases, particularly ones started before 2022.

Installing Yup

npm install yup

A Basic Yup Schema

// lib/validators/user-schema.ts
import * as yup from "yup";

export const userSchema = yup.object({
  name: yup.string().min(2, "Name must be at least 2 characters").required(),
  email: yup.string().email("Please enter a valid email address").required(),
  age: yup.number().integer().positive(),
  website: yup.string().url(),
});

// Yup's type inference — functional, but less precise than Zod's
export type User = yup.InferType<typeof userSchema>;

What's happening here: the shape looks similar to Zod at a glance, but notice .required() — in Yup, fields are optional by default unless you explicitly mark them required, which is the opposite of Zod's default (Zod fields are required unless you call .optional()). This trips up a lot of developers switching between the two.

⚠️ Common Mistake: Forgetting .required() on a Yup field and assuming it behaves like Zod. Yup schemas silently allow undefined on any field you don't explicitly mark required — this is one of the most common Yup-related bugs in production forms.

Validating Data with Yup

try {
  const validData = await userSchema.validate(
    { name: "Ali", email: "not-an-email" },
    { abortEarly: false }
  );
  console.log(validData);
} catch (err) {
  if (err instanceof yup.ValidationError) {
    console.log(err.errors); // ["Please enter a valid email address"]
  }
}

What's happening here: Yup's .validate() is async by default and returns a Promise — this is a real difference from Zod, where safeParse is synchronous unless you specifically opt into safeParseAsync. abortEarly: false tells Yup to collect every validation error instead of stopping at the first one. For a version that never throws, Yup also offers validateSync() with a try/catch, or you can check .isValid().

Yup in a Next.js Server Action

// actions/create-user.ts
"use server";

import { userSchema } from "@/lib/validators/user-schema";
import { ValidationError } from "yup";

export async function createUser(prevState: unknown, formData: FormData) {
  try {
    const data = await userSchema.validate(
      {
        name: formData.get("name"),
        email: formData.get("email"),
      },
      { abortEarly: false }
    );

    // await db.user.create({ data });
    return { success: true };
  } catch (err) {
    if (err instanceof ValidationError) {
      const fieldErrors: Record<string, string[]> = {};
      for (const e of err.inner) {
        if (e.path) fieldErrors[e.path] = [...(fieldErrors[e.path] ?? []), e.message];
      }
      return { errors: fieldErrors };
    }
    throw err;
  }
}

Notice this requires a try/catch and manually reshaping err.inner into a field-keyed object — Zod's flatten().fieldErrors gives you that shape for free.

Zod vs Yup: Side-by-Side

	Zod	Yup
TypeScript inference	Automatic, precise (`z.infer`)	Functional but looser (`InferType`)
Default field behavior	Required by default	Optional by default
Validation style	Sync by default (`safeParse`), async available	Async by default (`.validate()`)
Error shape	Structured `ZodError` with `.flatten()`	`ValidationError` with `.inner` array
Bundle size (gzipped)	Zod is slightly larger, but the difference <br/> is usually too small to matter for real <br/> applications.	Slightly smaller
React Hook Form support	✅ via `@hookform/resolvers/zod`	✅ via `@hookform/resolvers/yup`
Ecosystem fit	tRPC, modern Next.js patterns, Server Actions	Formik, legacy React form codebases
Learning curve	Slightly more API surface	Simpler, more forgiving for JS-first teams
Best for	New TypeScript projects	Existing Formik/Yup codebases

💡 Tip: Bundle size differences here are small enough that they shouldn't be your deciding factor for most apps — a few KB gzipped rarely matters next to your actual app code and images.

Using Either One with React Hook Form

This is where a lot of real-world decisions actually get made, so it's worth showing both side by side. Both integrate through the same @hookform/resolvers package.

npm install react-hook-form @hookform/resolvers

With Zod:

"use client";

import { useForm } from "react-hook-form";
import { zodResolver } from "@hookform/resolvers/zod";
import { z } from "zod";

const formSchema = z.object({
  email: z.email(),
  password: z.string().min(8, "Password must be at least 8 characters"),
});

type FormValues = z.infer<typeof formSchema>;

export function LoginForm() {
  const { register, handleSubmit, formState: { errors } } = useForm<FormValues>({
    resolver: zodResolver(formSchema),
  });

  const onSubmit = (data: FormValues) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("email")} />
      {errors.email && <p>{errors.email.message}</p>}

      <input type="password" {...register("password")} />
      {errors.password && <p>{errors.password.message}</p>}

      <button type="submit">Log in</button>
    </form>
  );
}

With Yup:

"use client";

import { useForm } from "react-hook-form";
import { yupResolver } from "@hookform/resolvers/yup";
import * as yup from "yup";

const formSchema = yup.object({
  email: yup.string().email().required(),
  password: yup.string().min(8, "Password must be at least 8 characters").required(),
});

type FormValues = yup.InferType<typeof formSchema>;

export function LoginForm() {
  const { register, handleSubmit, formState: { errors } } = useForm<FormValues>({
    resolver: yupResolver(formSchema),
  });

  const onSubmit = (data: FormValues) => console.log(data);

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register("email")} />
      {errors.email && <p>{errors.email.message}</p>}

      <input type="password" {...register("password")} />
      {errors.password && <p>{errors.password.message}</p>}

      <button type="submit">Log in</button>
    </form>
  );
}

What's different: almost nothing at the React Hook Form layer — swap the resolver, swap the schema syntax, and everything else stays identical. This is exactly why the "which one" decision usually comes down to TypeScript ergonomics and team familiarity rather than form-library compatibility, since both are equally well supported.

Async Validation: Where Yup Still Has an Edge

If you need to check something against a server mid-validation — "is this username already taken?" — Yup's .test() method has had mature async support for years:

const signupSchema = yup.object({
  username: yup.string().test(
    "unique-username",
    "This username is already taken",
    async (value) => {
      if (!value) return true;
      const res = await fetch(`/api/check-username?u=${value}`);
      const { available } = await res.json();
      return available;
    }
  ),
});

Zod supports async refinements too, using .refine() with an async function and safeParseAsync():

const signupSchema = z.object({
  username: z.string(),
}).refine(
  async (data) => {
    const res = await fetch(`/api/check-username?u=${data.username}`);
    const { available } = await res.json();
    return available;
  },
  { message: "This username is already taken", path: ["username"] }
);

// must use safeParseAsync, not safeParse, when the schema has async refinements
const result = await signupSchema.safeParseAsync({ username: "ali" });

What's happening here: both libraries can do this — Yup's API was simply designed around async validation from the start, so it reads slightly more naturally. Zod requires you to remember to swap safeParse for safeParseAsync whenever an async .refine() is in play, which is an easy thing to forget.

⚠️ Common Mistake: Calling safeParse() (not safeParseAsync()) on a Zod schema with an async .refine(). It won't throw — it'll just resolve the refinement incorrectly, since Zod can't await inside a synchronous parse. Always match safeParseAsync to async refinements.

Migrating from Yup to Zod (If You're Considering It)

If you're weighing a migration, here's the honest advice: don't rewrite a working Yup codebase just to switch libraries. The type-safety gains are real, but they're not worth the regression risk on schemas that already work in production. Reach for Zod on new features or new projects instead, and let old Yup schemas retire naturally as you touch that code for other reasons.

If you are migrating a specific schema, the field-by-field mapping is usually mechanical:

Yup	Zod
`yup.string().required()`	`z.string()`
`yup.string().optional()`	`z.string().optional()`
`yup.string().email()`	`z.email()`
`yup.number().integer()`	`z.number().int()`
`yup.object().shape({...})`	`z.object({...})`
`yup.InferType<typeof schema>`	`z.infer<typeof schema>`

Frequently Asked Questions

Can I use Zod without TypeScript?

Yes, Zod works fine in plain JavaScript — but you lose its single biggest advantage, since type inference only matters if you have TypeScript to infer into. If your project is JavaScript-only, Zod and Yup are much closer in practical value, and team familiarity should decide it.

Is Zod always faster than Yup?

Not necessarily, and it depends heavily on the shape of your schema. For most typical form-sized payloads, both validate in well under a millisecond, so raw performance differences almost never matter in practice — TypeScript ergonomics and API fit are the more meaningful factors.

Do I need to rewrite my Formik forms to use Zod?

No. Formik and Yup are still a perfectly fine, actively maintained combination for existing codebases. Only reach for a migration if you're already refactoring that form layer for other reasons.

Which one works better with tRPC?

Zod, by a wide margin — tRPC's input/output validation is built with Zod's type inference in mind, and most tRPC examples and starter templates assume Zod. Yup can technically be adapted, but it's fighting the grain.

Can I use both Zod and Yup in the same project?

Technically yes, but it's not something to do on purpose. If you're migrating incrementally, it's fine to have both installed temporarily — just avoid mixing them within the same feature or form, since their default behaviors (required vs. optional fields, sync vs. async) differ enough to cause confusing bugs.

Does Zod support transforming data, not just validating it?

Yes — .transform() lets you reshape data as part of validation, like converting a string date into a Date object. Yup supports this too, through .transform() on its schemas. Both are equally capable here.

Wrapping Up

Zod and Yup solve the exact same problem — turning "hope the data is right" into "know the data is right" — but they were built for different eras of the JavaScript ecosystem. Zod's schema-is-the-type approach is what modern TypeScript tooling expects in 2026, and it's the right default for anything new you're building. Yup remains a completely legitimate choice if you're maintaining an existing Formik-based app, and there's no urgency to rip it out just because a newer library exists.

If you're starting a project today: reach for Zod, pair it with @hookform/resolvers/zod for your forms, and use .safeParse() on the server inside every Server Action or API route that touches user input — never trust that client-side validation alone is enough.

Try This Free Developer Tool

Zod Schema Generator — paste a JSON sample or a TypeScript interface and get a production-ready Zod schema instantly, complete with smart field-name inference, a live validator, and ready-to-use React Hook Form, API Route, and Server Action output.

Continue Learning

Asking the user for input until they give a valid response java

Wed, 03 Jun 2026 12:26:01 +0000

As a Java developer, you will often find yourself in situations where you need to ask the user for input and validate it before moving forward in your program. Whether it's asking for a number within a certain range, a valid email address, or any other type of input, it's essential to ensure that the user's input is valid before proceeding.In this article, we will explore how to repeatedly ask the user for input until they give a valid response using Java. We will look at examples of how to accomplish this task using while loops, the Scanner class, and regular expressions. Whether you're a beginner or an experienced Java developer, this article will provide you with the tools you need to ensure that your program only receives valid input from the user. So let's dive in and learn how to ask the user for input until they give a valid response in Java!

The Scanner class

The Scanner class in Java is used to read input from various sources, such as the keyboard, files, and network sockets. Some of the useful methods it contains are:

nextLine(): Reads the next line of input as a String. Example usage:

Scanner scanner = new Scanner(System.in);
System.out.println("Enter your name:");
String name = scanner.nextLine();
System.out.println("Hello, " + name + "!");

nextInt(): Reads the next token of input as an int. Example usage

Scanner scanner = new Scanner(System.in);
System.out.println("Enter an integer:");
int num = scanner.nextInt();
System.out.println("You entered: " + num);

nextDouble(): Reads the next token of input as a double. Example usage:

Scanner scanner = new Scanner(System.in);
System.out.println("Enter a decimal number:");
double num = scanner.nextDouble();
System.out.println("You entered: " + num);

nextBoolean(): Reads the next token of input as a boolean. Example usage:

Scanner scanner = new Scanner(System.in);
System.out.println("Are you a student? (true/false)");
boolean isStudent = scanner.nextBoolean();
System.out.println("You are a student: " + isStudent);

hasNext(): Returns true if the scanner has another token in its input. Example usage:

Scanner scanner = new Scanner(System.in);
while (scanner.hasNext()) {
    System.out.println(scanner.next());
}

hasNextLine(): Returns true if the scanner has another line of input. Example usage:

Scanner scanner = new Scanner(System.in);
while (scanner.hasNextLine()) {
    System.out.println(scanner.nextLine());
}

next(): Reads the next token of input as a String. Example usage:

Scanner scanner = new Scanner("Hello, world!");
System.out.println(scanner.next()); // Output: "Hello,"

useDelimiter(String pattern): Specifies a delimiter to be used by the scanner to separate input tokens. Example usage:

Scanner scanner = new Scanner("Hello, world!");
scanner.useDelimiter(" ");
System.out.println(scanner.next()); // Output: "Hello,"

close(): Closes the scanner and releases any resources associated with it. Example usage:

Scanner scanner = new Scanner(System.in);
// Do some scanning here...
scanner.close();

Note It is important to note that when a Scanner is closed, it can no longer be used, and attempting to do so will result in an IllegalStateException.

Examples of input validation

In Java, you can use a while loop to repeatedly ask the user for input until they give a valid response. You can use the Scanner class to read input from the user and check if it is valid using an if statement. Here is an example of how you might ask the user for an integer input and check if it is within a certain range:

import java.util.Scanner;

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        int input;
        while (true) {
            System.out.println("Enter an integer between 1 and 10:");
            input = scanner.nextInt();
            if (input >= 1 && input

Another example of asking user for input and validating it until a valid input is given is for a string input, such as an email address:

import java.util.Scanner;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

public class Main {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        String email;
        final String EMAIL_REGEX = "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Z|a-z]{2,}$";
        
        while (true) {
            System.out.println("Enter an email address:");
            email = scanner.nextLine();
            Pattern pattern = Pattern.compile(EMAIL_REGEX);
            Matcher matcher = pattern.matcher(email);
            if(matcher.matches()){
                break;
            }
            System.out.println("Invalid email. Please try again.");
        }
        System.out.println("Thank you for entering a valid email.");
    }
}

Note in the above example we used a regular expression to validate the email address, which is a powerful tool for validating different inputs.

A simple guessing game

In this section, we are going to create a simple guessing game to illustrate a practical approach of using input validation.

import java.util.Scanner;

public class GuessingGame {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);
        int secretNumber = (int) (Math.random() * 100) + 1; // Generates a random number between 1 and 100
        int guess;

        System.out.println("I'm thinking of a number between 1 and 100. Can you guess what it is?");
        do {
            while (!scanner.hasNextInt()) {
                System.out.println("Invalid input. Please enter a number:");
                scanner.next();
            }
            guess = scanner.nextInt();
            if (guess < secretNumber) {
                System.out.println("Too low. Try again:");
            } else if (guess > secretNumber) {
                System.out.println("Too high. Try again:");
            }
        } while (guess != secretNumber);

        System.out.println("Congratulations! You guessed the number!");
        scanner.close();
    }
}

In this example, the program generates a random number between 1 and 100, and then prompts the user to guess what the number is. The program uses a do-while loop to repeatedly ask the user for input until they guess the correct number. The scanner.hasNextInt() method is used to check if the user's input is a valid integer, and if not, the program prompts the user to enter a valid number. Once the user enters the correct number, the loop exits, and the program prints a message congratulating the user for guessing the number.

Note It is important to close the scanner object after you have finished using it to release the associated resources and avoid memory leaks

Conclusion

In conclusion, asking the user for input and validating it is an essential task for any Java developer. By using while loops, the Scanner class, and regular expressions, you can repeatedly ask the user for input until they give a valid response. The examples provided in this article demonstrate how to accomplish this task for both integer and string input, but the principles can be applied to any type of input. It's important to note that validation of user input is a crucial step in ensuring the integrity of your program and protecting it from potential errors or malicious attacks. By following the techniques discussed in this article, you'll be well on your way to creating robust and secure Java programs that only accept valid input from the user.

References

The Java Scanner class documentation: https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/Scanner.html
Oracle's Java tutorial on regular expressions: https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/regex/Pattern.html

Why did I create vue-uform

Thu, 21 Aug 2025 02:07:44 +0000

In Vue, we already have the very convenient v-model syntax sugar. It handles two essential things for us:

When a JavaScript variable has a value, it fills the input field.
When the input changes, the new value is passed back to JavaScript.

That’s basically what v-model does under the hood.

So why redefine two-way binding?

The reason is that I’ve been exploring a new approach to form validation. I believe the next generation of Vue form validators should be:

Component-driven – the form behavior is powered by components, not configuration.
Style-agnostic – no built-in styling, leaving developers free to define layouts.
Flexible with UI libraries – should work seamlessly with input components from libraries like Naive UI, Element Plus, or even fully custom ones.

What existing validators do

When I looked at existing solutions, I found a common pattern: each form field usually comes with:

A label
An input
A help message
An error message (shown when validation fails)

Some libraries solve this by bundling their own input components and tightly integrating them with validation. While this works, it reduces flexibility.

I wanted something different: a validator that lets developers use their own UI components, while still handling value binding and validation logic cleanly.

The idea: u-field component

To achieve this, I introduced the idea of a u-field component.
You can put any input component into its slot.

The u-field exposes two key bindings to its slot:

value passes the form data down to the input.
update sends the new input value back up to the form.

This makes synchronization possible, and sets the stage for validation.

For example:

<template>
  <u-field v-slot="{ value, update }">
    <input :value="value" @input="($event) => update($event.target.value)" />
  </u-field>
</template>

Why not just v-model?

Looking at Vue’s official docs, this is exactly the kind of code v-model was meant to simplify.
But when binding with parent components (not just local state), we need another kind of syntax sugar.

So, inspired by vue-macros, I created a Vite plugin to introduce a new directive: f-model.

With f-model, the example above becomes:

<u-field v-slot="{ value, update }">
  <input f-model />
</u-field>

Beyond text inputs

Of course, text inputs are the simplest case.
For other components like radio buttons, checkboxes, or selects, special handling is still needed.

For third-party components, it’s straightforward:

With a regular input:

<input f-model />

With Naive UI’s n-input (which uses v-model:value):

<n-input f-model:value />

I built vue-uform – a unstyled, component-driven form validation library for Vue 3

Mon, 18 Aug 2025 20:25:28 +0000

Hey everyone

I’ve been working on a Vue 3 form library called vue-uform, and I think it might be useful for folks who want flexible, unstyled, component-driven form validation without the boilerplate.

Why I built it

Most form libraries either:

Come with a bunch of built-in styles that don’t match your design system, or
Require too much JS/TS setup for simple forms.

vue-uform takes a different approach:

No built-in styles – you have full control over HTML & CSS.
Treats components as first-class citizens – validation, data flow, and UI are all component-based.
Works with any UI library (Element Plus, Naive UI, etc.).
Supports built-in & custom validation rules (inspired by FormKit).

Quick Example

<script setup>
const formValues = { username: '', password: '' }

function doLogin(data) {
  console.log(data)
}
</script>
<template>
  <u-form :values="formValues" @submit="doLogin">
    <u-field name="username" label="Username" validation="required" v-slot="{ value, update }">
      <input f-model />
    </u-field>

    <u-field name="password" label="Password" validation="required|min:6" v-slot="{ value, update }">
      <input type="password" f-model />
    </u-field>

    <u-submit>Login</u-submit>
  </u-form>
</template>

That f-model directive is provided by a small Vite plugin – it’s like v-model but tailored for form fields.

✅ Built-in validation rules include:

required, number, email, between, starts_with, url, and more – you can also add your own custom rules with parameters

Example custom rule:

<script setup lang="ts">
function isfruit(node: FieldNode): boolean | string {
  const { value } = node;
  if (value.value != "apple" && value.value != "banana") {
    return "this value is not apple or banana";
  }
  return true;
}
</script>
<template>
    <u-field
      name="fruit"
      label="Fruit"
      help="please input a fruit"
      :rules="{ isfruit }"
      validation="required|isfruit"
      v-slot="{ value, update }"
    >
      <input f-model />
    </u-field>
</template>

Installation

pnpm install vue-uform
pnpm install @vue-uform/vite-plugin -D

Links

GitHub: https://github.com/tu6ge/vue-uform

StackBlitz: https://stackblitz.com/~/github.com/tu6ge/vue-uform-example