Right now the form validation in CreateFatePool.tsx is done manually using regex, parseFloat, and isNaN checks inside validateCurrentStep() and also separately in src/lib/validation.ts. Both files validate the same fields like addresses and fees but in different ways, so there is no single source of truth.
FormData.ts is just a plain TypeScript interface with no runtime checks, meaning invalid values can pass through silently.
Zod is already pulled in as a transitive dep via @rainbow-me/rainbowkit -> zod@3.25.76 visible in package-lock.json, so there is no new package being introduced conceptually.
What needs to be done:
- Add zod explicitly to dependencies in package.json
- Define a
FormDataSchema in src/components/Forms/FormData.ts and infer the type from it
- Refactor validateCurrentStep() to use .safeParse() per step
- Remove the overlapping address and fee validators from
src/lib/validation.ts that duplicate form-level logic
Not urgent since the current validation works, but should be addressed before adding more form steps to avoid making the inconsistency worse.
Right now the form validation in
CreateFatePool.tsxis done manually using regex, parseFloat, and isNaN checks insidevalidateCurrentStep()and also separately insrc/lib/validation.ts. Both files validate the same fields like addresses and fees but in different ways, so there is no single source of truth.FormData.tsis just a plain TypeScript interface with no runtime checks, meaning invalid values can pass through silently.Zod is already pulled in as a transitive dep via @rainbow-me/rainbowkit -> zod@3.25.76 visible in package-lock.json, so there is no new package being introduced conceptually.
What needs to be done:
FormDataSchema in src/components/Forms/FormData.tsand infer the type from itsrc/lib/validation.tsthat duplicate form-level logicNot urgent since the current validation works, but should be addressed before adding more form steps to avoid making the inconsistency worse.