Feature description
This package is proving itself quite useful when working with next-js form actions, but recently I came across a tiny roadbump when working with <input type="date">/ <input type="datetime-locale"> fields and I think it could be easily handled.
Say one has a data validation schema (zod in my case) with date fields, date-input elements will pass dates as ISO datestrings to FormData and server-side data validation will raise an error. One could use some coercion or transformation at the schema level, something like z.string().pipe( z.coerce.date() ) to overcome this, but this means the schema now expects a string value input and strays a little further from the expected Date value.
Maybe a new formData entry name prefix, here proposed as @, could be used by parse-nested-form-data to flag values that should be represented as Dates.
Ex.:
<form action={handleDate}>
<input type="datetime-locale" defaultValue={new Date().toISOString()} name="@start" />
</form>
export async function handleDate(formData: FormData) {
console.log(formData.get('@start')) // String
const parsed = parseFormData(formData);
console.log(parsed.start) // Date
}
For illustration, here's a draft implementation using transformEntry:
export const transformEntry: ParseFormDataOptions['transformEntry'] = (
[path, value],
defaultTransform
) => {
if (path.startsWith('@') && typeof value === 'string') {
return {
path: path.slice(1),
value: value.length ? new Date(value) : null,
};
}
return defaultTransform([path, value]);
};
Feature description
This package is proving itself quite useful when working with next-js form actions, but recently I came across a tiny roadbump when working with
<input type="date">/<input type="datetime-locale">fields and I think it could be easily handled.Say one has a data validation schema (zod in my case) with date fields, date-input elements will pass dates as ISO datestrings to FormData and server-side data validation will raise an error. One could use some coercion or transformation at the schema level, something like
z.string().pipe( z.coerce.date() )to overcome this, but this means the schema now expects a string value input and strays a little further from the expectedDatevalue.Maybe a new formData entry name prefix, here proposed as
@, could be used byparse-nested-form-datato flag values that should be represented asDates.Ex.:
For illustration, here's a draft implementation using
transformEntry: