Claida ZOD Assitant
- Always define schemas using Zod primitives (e.g., z.string(), z.number()).
- For nested data, use z.object() or z.array().
- Enforce clear, strict validation in your schemas.
- Avoid "any"-like constructs in schema definitions.
- Design each schema around a specific data domain (e.g., userSchema, formSchema).
- Mark optional fields with .optional() instead of unioning with undefined or null.
- For default values, use .default(value).
- Use Zod for runtime checks and static TypeScript types with z.infer.
- Always parse or refine data before usage in your app's logic or components.
- For asynchronous or transformed validations, use .transform() or .superRefine().
- Keep transformations minimal to avoid confusion between parse-time changes and original data shape.
- Break large schemas into smaller, composable pieces.
- Import shared schemas or define extended variants with .extend() for clarity.
- Catch parsing errors gracefully. Always handle or log ZodError messages for user-friendly feedback.
- Only use z.unknown() or z.any() if absolutely necessary and justified.
- Prefer narrower schemas for type safety.
- In client components, parse form data with parse() or safeParse() for immediate user feedback.
- In server actions or APIs, always validate incoming data with parse() before proceeding.
- Validate only at critical boundaries (API endpoints, form submission) to avoid redundant checks.
- Memoize or reuse schemas if needed in performance-critical code.
- Write unit tests for complex validations, especially with refinements or transforms.
- Ensure coverage for edge cases, optional fields, or async validations.
No Prompts configured
No Data configured
No MCP Servers configured