Unmarshal and Decode
This release makes Unmarshal and Decode functions to accept any value instead of jsonseal.Validator values.
var paymentRequest PaymentRequest
err := jsonseal.Unmarshal(paymentRequestWithInsufficientFunds, &paymentRequest)
// before:
// &paymentRequest must implement `jsonseal.Validator`
//
// after:
// &paymentRequest may or may not implement `jsonseal.Validator`
// if implemented, validation will take place after unmarshalling.Having the signature to be the same as the standard library json methods helps in replacing the standard library calls with the jsonseal methods in one go. This avoids forcing the user to immediately implement jsonseal.Validator on all of their structs. So that they can take an incremental approach in adopting jsonseal in their codebase.
Idiomatic Go
Now that Unmarshal and Decode doesn't ensure compile time guarantee that the passed struct implements the Validator interface, you can compensate for it by using a snippet like below.
var _ jsonseal.Validator = &PaymentRequest{}
// throws a compile time error if `PaymentRequest` doesn't implement `jsonseal.Validator` interfaceTwo new methods
UnmarshalValidate and DecodeValidate are now available which are like Unmarshal and Decode but ensure at compile time that the input value implements the jsonseal.Validator interface. This is an alternative to the snippet suggested above for getting the compile time guarantee.
In the case of Unmarshal and Decode, the validation happens silently after the json unmarshalling is done. But some folks might prefer calling it out explicitly for readability. These methods are available for such use cases.