Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect Data Type Handling in json-enc Extension #3125

Open
xehrad opened this issue Jan 12, 2025 · 0 comments
Open

Incorrect Data Type Handling in json-enc Extension #3125

xehrad opened this issue Jan 12, 2025 · 0 comments

Comments

@xehrad
Copy link

xehrad commented Jan 12, 2025

Hello,
I’ve noticed that the json-enc extension currently encodes all input values as strings, even when dealing with <input type="number"> fields. This behavior can lead to incorrect data representation in the resulting JSON when numeric values are expected.

To maintain backward compatibility while providing flexibility, I propose introducing an optional attribute (e.g., data-json-parse-data) that allows users to opt-in to automatic type parsing. When this attribute is present on the <form> element, the extension could:

  1. Convert values from <input type="number"> into actual numbers using Number().
  2. Keep the current behavior (encoding everything as strings) when the attribute is not present.

Example usage:

<form hx-ext="json-enc" hx-post="/api/endpoint" data-json-parse-data>  
  <input type="text" name="name" value="mehrad">  
  <input type="number" name="age" value="25">  
</form>

Expected JSON output with data-json-parse-data attribute:

{ "name": "mehrad", "age": 25 }

Without the attribute, the JSON output would remain:

{ "name": "mehrad", "age": "25" }

Would this feature be acceptable as a non-breaking enhancement? If you believe it’s a good idea, I would be happy to submit a PR for it.

Thanks in advance for your feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant