fabian-hiller/decode-formdata

Decodes complex FormData into a JavaScript object

decode-formdata's Issues

Another notation for FormDataInfo

What do you thing about a new notation for FormDataInfo? Something that looks more like the object that will get returned:

const formValues = decode(formData, {
  title: 'string',
  price: 'number',
  created: 'date',
  active: 'boolean',
  tags: ['string'],
  images: [{
      title: 'string',
      created: 'date',
      file: 'file',
    }]
  ,
});

Benefits:

• imho the DX is better: I know how my object should look like in the end. Its way easier to write down the object compared to paths where I want a transformation to happen.
• It pretty much looks like a valibot / zod schema. So switching between "pure" FormDataInfo and a Schema is super easy

Boolean strings

One issue I ran into was that the decode function doesn't parse "true" or "false" strings to their corresponding boolean values. Both just result in true. To get false, you need to exclude the field from the form data altogether.

I think this could be an area for improvement.

• True: any value, except "false", "0"
• False: "false", "0", excluded

Multiple entries with same name should turn into array

Hey!

I just noticed that handling multiple entries with the same name will result in a single prop with the last value. Coming from plain ol HTML forms, I would expect that they turn into an array.

This situation occurs when I have multiple checkboxes with the same name, or (more problematic) a multi select:

<form id="myForm">
    <input type="checkbox" name="pets" value="cat" />
    <input type="checkbox" name="pets" value="dog" />
    <input type="checkbox" name="pets" value="pig" />
    
    <select name="colors" multiple>
        <option>Blue</option>
        <option>Red</option>
        <option>Gold</option>
    </select>
</form>

const formData = new FormData($('#myForm'));

Array.from(formData);
// [
//     ['pets', 'cat']
//     ['pets', 'dog']
//     ['colors', 'Red']
//     ['colors', 'Gold']
// ]

decode(formData, { arrays: ['pets', 'colors'] })
// {
//     pets: 'dog',
//     colors: 'Gold'
// }

I would expect to receive an array, if the same key is found multiple times, regardless if it's defined in the FormDataInfo or not. But the info need to be configured properly, to enforce receiving an array, if only a single value is selected, as we can not differentiate it from single value entries.

What do you think?

Empty dates

Found one more issue related to dates. If a user leaves a date field empty, it returns as "" and the decode function will return Invalid Date. This will cause a schema to fail, even if it accepts empty dates.

I currently handle it like this:

const formValues = decode(formData, {
	...info,
	dates: info?.dates?.filter((d) => formData.get(d)) // filter empty strings
});

This ensures they show up as "" after decoding.

Cannot decode date if timestamp is a string

Formdata content is always stored as a string. So if I am sending a Timestamp to the server it will be converted to a string and fail.

Repro

const formData = new FormData()
formData.append('createdDate', new Date().getTime())
const data = decode(formData, { dates:['createdDate'] })
console.log(data)

Demo

Expected

{
  createdDate: 2020-02-20T00:00:00.000Z
}

Actual

{
  createdDate: Invalid Date
}

Suggestion

• Parse the string timestamp
• provide documentation on what the decoder should expect for date input
• provide best practice on what to store the date as on the browser

Addtional Info

btw, your package is awesome.

Fully type the value paths of the seconds argument using a generic

I think that we can fully type the value paths of the seconds argument of the decode function using a generic. This way, we can make the API fully type safe. All we need to do is resolve the path of each data type in TypeScript. I have already implemented this in a similar way for Modular Forms.

Furthermore, my idea is that if a generic is specified, for example decode<MyType>(...), the return type of decode is still Record<string, unknown>, and this behavior can be controlled by a second generic, for example a boolean. So decode<MyType, true>(...) would have the return type MyType.