Add a new function that accepts an interface instead of byte slice to diff against

[justinrixx]

I'm using github.com/yalp/jsonpath in a project used for testing my apis. It allows me to just look at the subset of the response payload that i'm interested in for the relevant test case. That package returns an interface{} for the value at the specified path instead of a []byte. I have a use-case where I'd like to perform a superset match on a map in the payload.

For example, my api returns something like:

{
    "settings": {
        "localization": {
            "language": "foo"
        },
        "meta": {
            "lastModified": "bar",
            "displayName": "baz",
            "file": {
                "size": "bar",
                "type": "baz"
            }
        }
    }
}

In my test I want to verify some of the values under settings.meta. specifically the displayName string and file map. yalp/jsonpath returns me an interface{} which i can then cast to map[string]interface{} for everything under settings.meta. If I then want to jsondiff.Compare it I have to json.Marshal it back to a []byte.

Today, jsondiff.Compare immediately decodes the []byte into interface{} objects. Why not introduce a new public function that just takes the first parameter as an interface{} to avoid needing to re-marshal before the call? Then the assertion could look like:
jsondiff.CompareInterface(metaInterface, []byte(`{"displayName":"baz","file":{"size":"bar","type":"baz"}}`))

[nsf]

There could be some concerns with that kind of interface. Yes, internally lib compares things using interface{} representation of the JSON AST as produced by the Go encoding/json lib. But I can't say lib accepts any interface{}, because that's not true. For example code inside expects you to use UseNumber() on go's json decoder, and never checks for float64 or int64 type in the interface{} typed values. Those types are replaced by json.Number.

Effectively we'll have to say something like: Here's the CompareValues(a, b interface{}, opts *Options) function, but a and b values must be a result of: d := json.NewDecoder(input); d.UseNumber(); d.Decode(). Which is a strange kind of interface to have. Not sure it's worth the effort.

Another argument against it, is that this lib is just used for testing, in tests you can encode the JSON to []byte and feed it to the lib without thinking about performance. I doubt it will make your tests drastically slower. The lib in general is not that optimized for performance anyway.

I'm not convinced about the need for such interface, but I'll leave the issue open, maybe will reconsider it one day.

And as a side note. This lib sadly is very far from the top of my maintenance effort list. I still use it in tests and it works for me, don't feel like changing anything. (This is more of a message for people who wonder why there are no commits and/or work on other issues)