Maintain formatting of float values like 1.0

[ghost]

A float value such as 1.0 should remain 1.0 and not be changed to 1 i.e. without the .0 on the end.

I know this has been raised a number of time before but they have been closed incorrectly.

The JSON specification for Number DOES treat integers and floats differently. See the spec - https://www.json.org/. You will notice that when a period is given there MUST be a following digit even if that digit is zero. This is how floats are distinguished from integers in JSON. It is incorrect to strip the ".0" from the end of a float and turn it into an integer.

[ghost]

I appreciate that 1.0 == 1. I also appreciate that JSON serialisers will happily deserialise 1 into a float/double although I note that Newtonsoft JSON .NET library (used by dotnet core framework) will always serialise a double/float to include the trailling .0.

All that said, https://jsoneditoronline.org/ is a fantastic editor and as an editor it should preserve what the user has entered unless it has an extremely good reason not to. 1.0 is a perfectly valid JSON number as per the specification and so it should be preserved as-is by the editor.

[josdejong]

It would indeed be nice to keep the number formatting unchanged, like 1.0 which is turned into 1, or 1e3 which is turned into 1000. The mathematical value is the same, but the formatting differs.

Keeping the formatting unchanged is far from trivial though, it means that we cannot parse numbers but have to keep them as formatted strings internally, ruling out using the default in JSON parser for example.

Just curious: why is the formatting of the number of importance to you?

[ghost]

I'm using jsoneditoronline to construct and manipulate data for use in unit tests for c# data structures that I store as JSON. One of my tests is to take JSON data, deserialise and then serialise it again and check I have same as I first started with. This is with Newtonsoft JSON where the serialisation of floats and doubles has trailing .0. Whenever I use jsoneditoronline to manipulate my test data it strips the trailing .0 and hence causes my tests to fail.

If I can help you fix this I'd be happy to although my javascript skills are not great.

[josdejong]

Does your JSON parser rely on the .0 to determine whether something is a float or integer? JSON and JavaScript do not distinguish between floats/integers, there is just the concept of a number.

[ghost]

My parser does not rely on that at all. The JSON spec does distinguish between floats and integers although I can see why JavaScript, as a typeless language, treats them indistinguishably.

Without digging into the code for jsoneditoronline, my guess would be that the minimal change needed would be to continue to hold number data items as numbers but to also hold a bool to indicate if the original number was read as a float or integer. Although, as you suggest, its perhaps more versatile to retain the original string value.

[josdejong]

If your parser doesn't rely on it, maybe you can change your unit tests such that they don't depend on how a number is formatted when serialized as JSON. The value of 1.0 is the same as 1 or 1e0 after parsing, only the formatting differs. That could be an easy fix on your side.

Changing this in JSONEditor is not trivial because currently a lot of stuff depends on parsing JSON into regular JavaScript objects, arrays, and numbers, where values are parsed into a JavaScript number. You would need to write a custom JSON parser, implement a custom internal model in JSONEditor which can hold numbers as strings (but distinquishable from "real" strings), and change the internals not to use checks like typeof value === 'number' and things like that.

[ghost]

I have worked around this for now by putting the .0 back in by hand.

My unit test is just Assert.AreEqual(startingJsonString, endingJsonString). Of course I can work around this in my unit test by manipulating one or other of these strings before the Assertion; although that does feel a little off.

As I mentioned I think a simple option is not to change the internals all all. Just to change the rendering parts so that when typeof value === 'number' you do somelike formatNumberAsOriginal(value,originalFormat)

[ghost]

To my mind this is not about JSON/JavaScript types but rather about whether a JSON editor should keep user input as entered unless the user changes it. I think it should although I appreciate that its not trivial by any means.

[josdejong]

I think we both agree that it would be great if JSONEditor would keep numeric inputs unchanged.

Thing is, this is a lot of work to address. Though the issue you bring up is just a "cosmetic" formatting issue, when working with long values the actual value can change, see #231.

Again, you may be able to work around this by comparing parsed JSON instead of stringified. The latter is not reliable in general, for example {"a":2,"b":3} does not equal {"b":3,"a":2} when comparing as string, whilst the JSON contents of these two objects is equal.

[ghost]

The long values case is interesting and I think its quite right that the editor should coerce the entered value to one which is valid JSON.

Also a good stringified comparison example.

Since we agree it would be nice to fix this please can you leave this issue open. Hopefully, someone will submit a patch...

Thank you for an excellent discussion about this.

[josdejong]

Yes thanks for your input 👍