You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some use cases, pre-condition for a given operation might be relaxed (e.g. the pre-condition that a deleted element has to exist).
An optional strict boolean field can be added to operations where it makes sense so that the operation doesn't fail if the pre-condition doesn't hold, and the operation is simply ignored.
This is not part of the standard, and the default behavior should be unchanged.
The text was updated successfully, but these errors were encountered:
At the moment the diff is correct, but correct isn't always helpful, and the signal to noise ratio of the diff could be improved by adding the ability to set some options. The three low hanging options I'd personally like to be able to specify are:
A missing key, and a key set to null are considered equal. I can get my JSON lib to do this for me in a pre-processing step, but it would be nice to just tell the differ to deal with it.
Object keys are sorted, so that order doesn't matter. This one may already work since I seem to recall it's part of the spec, I haven't checked.
Similarly, array order (globally is fine, unless you want to allow Pact style path based matching rules) can be ignored, i.e. as long as the array contains all the same things and is the same length, it's ok.
For some use cases, pre-condition for a given operation might be relaxed (e.g. the pre-condition that a deleted element has to exist).
An optional
strict
boolean field can be added to operations where it makes sense so that the operation doesn't fail if the pre-condition doesn't hold, and the operation is simply ignored.This is not part of the standard, and the default behavior should be unchanged.
The text was updated successfully, but these errors were encountered: