parseXYZ options

[KATT]

I don't like that the parseNumbers option automagically parses everything that looks like a number to numbers, it gets confusing as the backend receiving the data can be type sensitive and won't like to receive a number for a string field, just because you inputted something that looks like a number in a string field. I have the same issue with parseBooleans/parseNulls.

Possible alternatives:

• having a data attribute on inputs, i.e.

  <input type="text" name="Numeric -2.25" value="-2.25" data-serialize-number="true" />`

• passing an Array of the names you want to parse as numbers, i.e.

  obj = $form.serializeJSON({parseNumbers: ['Numeric -2.25'/*[, otherName ] [, .. ] )*/});

What do you think? Either solution could be added with backwards compatibility.

[marioizquierdo]

I like more the solution with the data argument.
Also, I think we could add a second (optional) argument to the parseWithFunction option, to send the input name.

The only problem with this would be to explain it properly in the README file without adding too much text/confusion to the plate.

[KATT]

I reckon the data arguments should be used to override the form's general options. I.e. correlating parseNumbers: true on a global level with being able to override it with data-sjson-parse-numbers="false".

[marioizquierdo]

That makes sense. I'll think about it and add an update sometime soon.
Thanks KATT!

[KATT]

Got tests added and a beginning of a solution with my parseInputValue method -- but need to wire it in somehow in a nice way. Ideas?

Will look at it more tomorrow.

[marioizquierdo]

To solve this problem, I implemented :types in the version 2.4.0.

Now you can specify a :type on every input by just appending the type with a colon. This way you can control which input is going to be parsed as string, number, boolean, null, array or object. Which for user-generated values is more safe than using the parse options, that will auto-detect the type to be parsed.

For the example input, the problem could be solved by appending :number to the input name:

<input type="text" name="Numeric -2.25:number" value="-2.25" />`

[KATT]

Mate, you should really do the :type thing as a data-attribute for the plugin rather than polluting the name field. 😿

[KATT]

I like the idea of

<input type="hidden" name="flags:array" value="[]"> 

However, I get a bad taste of changing the name field with plugin specific attributes.

Should be more like:

<input type="hidden" name="flags" value="[]" data-type="array"> 

[marioizquierdo]

Yes I know.

When I started implementing the "data-type" stuff I realized that it was going to complicate the code a great deal. It would mean that the plugin would no longer use serializeArray (because it would need to check field by field), and that is one of the reasons why serializeJSON works so well.

I would not like to compromise the simple case of using serializeJSON with no options and with same field names used to submit forms to a Rails backend.

Then, I had the idea of "polluting" the name format, because that can still be used with serializeArray. Well, it makes it more intrusive, and the form is no longer non-javascript compatible. But if someone really wants to change the type of the attribute, the form is already non standard. So it actually doesn't matter to change the field name format.