Thanks!
As I know JSON-format (and as online JSON-validators can proof), this is valid behaviour; also test by Python 'json'-module, it can be correctly parsable.
I mean, that values, which you can type in app form, can be different types - not only integer numbers, for example.
But you right, there are big field to app impovement, and may be somewhen I upgrade it.
I think it is perfectly understandable to only support string types given the time constraints of the jam!
However, I feel it is a bit misleading to call the field (int/float/string/bool) when it only accepts strings. The behavior of compliant parsers will differ if they get a different data type (strongly typed languages might even refuse to parse into a struct that has the incorrect type!). For example JSON exported from your tool behaves strangely when parsed in my browser:
According to the JSON spec (https://www.crockford.com/mckeeman.html) there is a difference between a string containing an integer (‘”’ characters ‘”’ e.g. "123"
) and an integer (onenine digits e.g. 123
).
I understand the confusion, as formal language grammar is complicated, and the many formats used don’t help at all. So I don’t think this is a serious deficiency in your tool, just maybe something to consider in the future 😉 I hope this did not come across as too negative, I rewrote this message several times to make it sound less unfriendly 😢. I just wanted to show that in JSON these things matter!
Thanks!
I do some additional test and understood, that you and Léon was right and plain types dont need to be 'strings' in result.
(...really, it can be - but only if after parse you convert fields by-hand, and this is terrible practice...)
Online validators fake me. =((
I update the tool when I can.
Sorry for unfunctional tool. =(