You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AI_USAGE_GUIDE.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Vest 6 — Consumer Usage Guide
2
2
3
-
Vest is a framework-independent, stateful validation runtime for complex forms and progressive workflows.
3
+
Vest is a validation library that keeps test results between runs and does not depend on a UI framework.
4
4
5
5
Use Vest when validation unfolds over time: only some fields should run, earlier results must remain available, fields depend on one another, or async checks can overlap.
Vest manages validation as values change over time. It runs only the relevant field or step, retains trustworthy results from earlier interactions, and prevents stale asynchronous work from replacing the current result.
9
+
Vest runs the tests for the field or step that changed and keeps the results for everything else. When async checks overlap, only the latest result can update the suite.
10
10
11
11
> **Vest validates what changed, remembers what already passed, and prevents stale async validation results.**
12
12
@@ -43,7 +43,7 @@ await result;
43
43
## Why Vest?
44
44
45
45
-**Incremental execution:** Validate a field, group, or step without rerunning everything.
46
-
-**Retained validation state:**Focused runs merge into one complete living result.
46
+
-**Retained validation state:**A focused run updates part of the existing result instead of replacing it.
47
47
-**Race-safe async:** Track pending work, cancel obsolete requests, and ignore stale completions.
48
48
-**Real workflow primitives:** Model dependent fields, conditional sections, warnings, optional values, groups, and dynamic lists.
49
49
-**Client and server continuity:** Run statelessly on the server and resume full validation state in the browser.
@@ -62,9 +62,9 @@ await result;
62
62
63
63
These layers are complementary. A common architecture uses a form manager for input mechanics, Vest for progressive interaction, and a schema validator for the final submitted boundary.
64
64
65
-
## Strong use cases
65
+
## Where Vest works well
66
66
67
-
Vest is particularly useful for:
67
+
Vest works well for:
68
68
69
69
- async username, email, inventory, coupon, or eligibility checks;
Vest manages validation as values change over time. It runs only the relevant field or step, retains trustworthy results from earlier interactions, and prevents stale asynchronous work from replacing the current result.
9
+
Vest runs the tests for the field or step that changed and keeps the results for everything else. When async checks overlap, only the latest result can update the suite.
10
10
11
11
> **Vest validates what changed, remembers what already passed, and prevents stale async validation results.**
12
12
@@ -43,7 +43,7 @@ await result;
43
43
## Why Vest?
44
44
45
45
-**Incremental execution:** Validate a field, group, or step without rerunning everything.
46
-
-**Retained validation state:**Focused runs merge into one complete living result.
46
+
-**Retained validation state:**A focused run updates part of the existing result instead of replacing it.
47
47
-**Race-safe async:** Track pending work, cancel obsolete requests, and ignore stale completions.
48
48
-**Real workflow primitives:** Model dependent fields, conditional sections, warnings, optional values, groups, and dynamic lists.
49
49
-**Client and server continuity:** Run statelessly on the server and resume full validation state in the browser.
@@ -62,9 +62,9 @@ await result;
62
62
63
63
These layers are complementary. A common architecture uses a form manager for input mechanics, Vest for progressive interaction, and a schema validator for the final submitted boundary.
64
64
65
-
## Strong use cases
65
+
## Where Vest works well
66
66
67
-
Vest is particularly useful for:
67
+
Vest works well for:
68
68
69
69
- async username, email, inventory, coupon, or eligibility checks;
Copy file name to clipboardExpand all lines: scripts/build-llms.js
+5-5Lines changed: 5 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -187,7 +187,7 @@ const sectionOrder = [
187
187
];
188
188
189
189
letllmsTxt=`# Vest 6
190
-
> TypeScript validation-state framework for complex interactive forms. Vest validates what changed, retains trustworthy previous results, and prevents stale async work from corrupting current state.
190
+
> Form validation written like unit tests. Vest validates what changed, keeps the other results, and ignores stale async responses.
191
191
192
192
- [Full Vest 6 documentation](https://vestjs.dev/llms-full.txt)
Copy file name to clipboardExpand all lines: website/docs/community_resources/standard_schema.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ function EmailForm() {
43
43
}
44
44
```
45
45
46
-
The resolver is the simplest path when the form manager should invoke complete validation. To use Vest's progressive runtime during interaction, also run the changed field through the same suite:
46
+
The resolver is the simplest option when the form manager should validate the whole form. To validate one field during interaction, run that field through the same suite:
Vest models validation as an evolving process, not just a function that parses an object once.
11
+
Most validators inspect a value and return an answer. Vest can do that too, but a suite can also keep its result between runs.
12
12
13
13
A schema validator usually answers:
14
14
15
15
> Does this value match the required structure right now?
16
16
17
-
Vest answers a different set of questions:
17
+
An interactive form has a few more questions:
18
18
19
-
> What changed? Which rules need to run? Which previous results are still trustworthy? Which async result is still current? Is the complete workflow ready to proceed?
19
+
> What changed? Which rules need to run again? Can the other results stay as they are? Is this async response still current? Can the user continue?
20
20
21
-
This is why Vest is particularly useful for complex forms, onboardingflows, wizards, configuration interfaces, and other progressive workflows.
21
+
Those questions come up in forms, onboarding, checkout flows, settings screens, and anywhere validation happens a little at a time.
22
22
23
-
## The three layers
23
+
## What a suite gives you
24
24
25
25
### 1. Executable business rules
26
26
@@ -42,9 +42,9 @@ const suite = create(data => {
42
42
43
43
The familiar syntax is valuable because it gives validation logic a consistent structure. Rules live outside UI components, support multiple tests per field, and can be unit-tested without simulating DOM events.
44
44
45
-
### 2. A living validation result
45
+
### 2. One result that updates over time
46
46
47
-
A suite is more than a validation function. It stores the current truth about the workflow.
47
+
A suite keeps the latest result for every test it has seen.
48
48
49
49
When `suite.run()` executes, Vest:
50
50
@@ -65,13 +65,13 @@ Username changes
65
65
→ ignore an older username request if it finishes late
66
66
```
67
67
68
-
This is Vest's central capability: **do the minimum new work without losing the conclusions already earned**.
68
+
The result is still complete even when the latest run only checked one field.
69
69
70
70
### 3. Assertions, schemas, and integration
71
71
72
72
`enforce` provides assertions, schemas, parsing, and custom rules. Vest suites and Enforce rules also implement Standard Schema for interoperability with compatible tools.
73
73
74
-
Schema validation answers structural questions before behavioral tests run. Stateful suite execution then manages how validation evolves during interaction.
74
+
The schema checks and parses the input. The suite then keeps track of test results as the user interacts with the form.
75
75
76
76
## Validation state, not form state
77
77
@@ -150,7 +150,7 @@ Real workflows are rarely independent field maps. Vest includes primitives for r
150
150
-`each()` tracks dynamic list items with stable keys;
151
151
- warnings provide guidance without blocking completion.
152
152
153
-
These are workflow concepts, not merely value matchers.
153
+
These tools describe relationships between tests, not just the shape of a value.
154
154
155
155
## Errors are not the same as incompleteness
156
156
@@ -166,12 +166,12 @@ That is different from an active validation error. Vest exposes `isTested`, `isP
166
166
167
167
Because suites do not depend on UI components, the same validation contract can be used with React, Vue, Svelte, Angular, vanilla JavaScript, or Node.js.
168
168
169
-
The framework decides when to invoke the suite and how to render it. Vest decides what validation work is relevant and maintains the resulting truth.
169
+
Your framework decides when to run the suite and how to show its result. Vest keeps track of the validation itself.
170
170
171
-
## The core idea
171
+
## In short
172
172
173
-
The test-like syntax makes Vest easy to learn. The stateful runtime is why it exists.
173
+
Vest's test-like syntax is familiar, but the state kept by the suite is the important part.
174
174
175
-
> **Vest validates what changed, remembers what already passed, and prevents stale asynchronous validation results.**
175
+
It lets you validate what changed without forgetting what already passed, and it prevents an old async response from overwriting a newer result.
176
176
177
177
Continue with [Understanding Vest's State](./understanding_state.md) or see [Vest alongside schema and form libraries](./vest_vs_the_rest.md).
Vest is a **stateful validation runtime for complex forms and progressive workflows**.
10
+
Vest is a validation library for forms and other flows that change over time.
11
11
12
-
It validates the field or step changing now, retains trustworthy results from earlier runs, and prevents obsolete asynchronous work from corrupting current validation state.
12
+
It can validate only the field or step that changed, keep the results from earlier runs, and ignore an old async response when a newer one has already finished.
13
13
14
14
If you know Jest or Mocha, the authoring model will feel familiar: define a suite of named tests and use assertions to express the rules. The test-like syntax makes Vest approachable; its persistent validation runtime is what makes it different.
15
15
16
16
import GetStartedSandpack from '@site/src/components/Sandpack/GetStarted';
17
17
18
18
## The problem Vest solves
19
19
20
-
Interactive validation is not a one-time parse. A real form unfolds over time:
20
+
Forms are rarely validated just once. While someone fills one out:
21
21
22
22
1. The user changes one field.
23
23
2. Only the related rules should run.
@@ -26,7 +26,7 @@ Interactive validation is not a one-time parse. A real form unfolds over time:
26
26
5. Async responses may arrive in the wrong order.
27
27
6. The complete workflow still needs one reliable validation result.
28
28
29
-
Vest owns that process without owning your form values, DOM, or UI components.
29
+
Vest handles the validation state without taking over your values, DOM, or components.
The test exercises the same rules as the UI without rendering a component. Interactive application code should still use stateful `run()` so focused results can accumulate over time.
106
106
107
-
## When Vest is a strong fit
107
+
## When Vest is useful
108
108
109
109
Use Vest when validation behavior includes:
110
110
@@ -116,12 +116,12 @@ Use Vest when validation behavior includes:
116
116
- errors, warnings, pending states, and progressive completion;
117
117
- validation shared between browser and server.
118
118
119
-
For a one-shot API boundary parse, an Enforce schema's `.parse()`API may be all you need. For progressive workflows, the same Enforce schema can be attached to a Vest suite so Vest owns both parsed output and the interactive journey. Zod or another schema library can also be composed at the boundary.
119
+
If you only need to parse an API payload once, an Enforce schema's `.parse()`method may be enough. Attach the same schema to a Vest suite when you also need validation while the user works through a form. You can use Zod or another schema library at the boundary instead if that is already part of your stack.
120
120
121
121
## Next steps
122
122
123
-
-**[Follow the ten-tutorial learning path](./tutorials.md)**: Build from a basic suite through async state, schemas, server validation, and custom rules.
124
-
-**[Understand Vest's living result](./concepts.md)**: Learn the stateful runtime mental model.
123
+
-**[Browse the tutorials](./tutorials.md)**: Start with a basic suite or jump to async checks, schemas, server validation, or custom rules.
124
+
-**[See how Vest handles validation](./concepts.md)**: Understand what the suite remembers between runs.
125
125
-**[Async validation without stale results](./writing_tests/async_tests.md)**: Coordinate overlapping server checks safely.
126
126
-**[Focused updates](./writing_your_suite/focused_updates.md)**: Validate one field, step, or group.
127
127
-**[Dependent fields](./writing_your_suite/including_and_excluding/include.md)**: Rerun related rules together.
0 commit comments