Add warning about forcing struct field order for JSON

[EriKWDev]

Non-compliance

According to the JSON spec, https://www.json.org/json-en.html, An object is an unordered set of name/value pairs. However, nanoserde's JSON requires files to have the exact same order as the struct internally or else it crashes.

It would be really great if this "non-compliant" order requirement was communicated up front in the README

Why this should be communicated

Thinking this is a great general JSON-parser, people might try to migrate their projects to this only to later realize that it won't necessarily work with files created by other tools.

This hit me hard when I was going to migrate my GLTF parser to nanoserde thinking it was a compliant JSON parser, but it really only parses files created by itself or in the exact internal order of the structs, but GLTF-json files are created by many other serializers that don't care about any specific order.

Example that fails

Here is a failing test that normal serde_json and miniserde handles:

#[test]
fn de_out_of_order() {
    #[derive(DeJson)]
    pub struct Test {
        pub a: f32,
        pub b: f32,
        c: Option<String>,
        d: Option<String>,
    }

    let json = r#"{
        "a": 1,
        "d": "hello"
        "b": 2.0,
    }"#;

    let test: Test = DeJson::deserialize_json(json).unwrap();
    assert_eq!(test.a, 1.);
    assert_eq!(test.b, 2.);
    assert_eq!(test.d.unwrap(), "hello");
    assert_eq!(test.c, None);
}

To be fair, makepad_tinyserde doesn't handle this either, but it's still not really documented anywhere that I can find

[knickish]

Thanks for reporting this, I mostly use the binary one so hadn't considered this. Will take a look through and either make it compliant or highlight that it is not in the README.

[Fedor Logachev]

It would be really great if this "non-compliant" order requirement was communicated up front in the README

Sure, feel free to send a PR!

[Fedor Logachev]

Just a side note, I got gltf parser that works just fine with blender-exported gltfs and gltfs from gltf-sample-models: https://github.com/not-fl3/nanogltf

Maybe it will require some hacks to get it works for some other gltf sources tho!

[knickish]

I've added the example test case to the json test suite, and it appears that the issue was the missing comma after "d": "hello" rather than an issue with the field ordering. After adding the comma, the test passes as expected

[EriKWDev]

That is embarassing. I tested it now and it seems to work.

But I am still very confused. It was a while ago and I of course might have done something wrong, but I was quite certain that it seemed to be a field order dependent thing that didn't allow me to use nanoserde for my gltf parser.

Once I switched it to serde it worked again.

I will return if I find out why it was the case