If dst contains a struct which is not embedded, we should recursively compare it. FieldMismatch will need to be updated to include something that describes the field's "path". Having a list of strings that keeps track of the parent would probably be the easiest approach.

https://github.com/Kangaroux/go-map-schema/blob/482c9d8b8f692a9017ad5a4633589cf79ab4cd91/schema_test.go#L113

json.Unmarshal doesn't discriminate between floats and ints. When unmarshaling into a interface{} it always stores it as a float64.

We should check when converting to an int field if there would be loss of data (i.e. truncating everything after the decimal). Unfortunately we can't tell the difference between 3 and 3.0. Technically 3.0 is a type mismatch, but there is no loss of data if we truncate it.

Currently when applying this code, every property gets reported back as missing wether its marked as required or not. I could make my own filter to fix that, but adding a simple isRequired property it would make this a lot easier.

I've come up with a backwards compatible way to still report all missing fields, but also giving the developer the option to decide wether or not to do something with the error:

type FieldMissing struct {
	/* Other fields here */ 	

	// IsRequired indicates whether or not the field is marked as required in the structs tags.
	IsRequired boolean
}

type FieldMismatch struct {
	/* Other fields here */ 	

	// IsRequired indicates whether or not the field is marked as required in the structs tags.
	IsRequired boolean
}

func contains(s []string, str string) bool {
	for _, v := range s {
		if v == str {
			return true
		}
	}

	return false
}

func fieldIsRequired(f reflect.StructField) (bool) {
	tag := f.Tag.Get("validate")
	if tag == "" {
		return false;
	}
	
	return contains(strings.Split(tags, ","), "required")
}

And then apply them in schema.go, eg:

missing := FieldMissing{Field: fieldName, IsRequired: fieldIsRequired(field)}
mismatch := FieldMismatch{ IsRequired: fieldIsRequired(field), /* */}

By "data validation" I mean validating the actual values of the payload, not just the types. For example, we may want to check that a field is not blank.

I'm hesitant to use the term "form validation" since this library isn't really for form validation. It can certainly be used to help with form validation, but it's a bit redundant. It's more appropriate to use this for an API meant for third party consumers.

The straightforward approach to using this library for data validation would be:

1. Input a JSON payload
2. Use CompareMapToStruct() to check the types, and return the errors if there are any
3. Unmarshal the JSON into dst and check the values using some validation logic, and return the errors if there are any

There are plenty of data validation libraries out there, like ozzo-validation, which would work pretty seamlessly with this.

We should support type checking arrays just like any other value.

I'm not sure what the best way of reporting type mismatches would be. The two things that come to mind would be to report the entire array as a mismatch, or to report each individual index as a mismatch.

Calling out the specific indexes that are mismatched would definitely be a bit too verbose in most cases. I'd also be willing to bet that if one of the indexes is mismatched then chances are the whole array is mismatched.

On the other hand, I'd rather be overly verbose and provide a way to simplify the mismatch reporting.