lllwvlvwlll
commented
4 years ago I think this works well in the SDK for now. So you are aware, the back-end using type validation instead of field validation (in most cases). I think we can move forward with this approach though and work to align the two. The format makes sense to me and there is nothing I see that would inhibit use in the backend in the future.
To solve https://github.com/Moonlight-io/asteroid-sdk-js/issues/46
@lllwvlvwlll would like to get your feedback on the proposed validator mechanism. This is designed to replace
vega's attribute validation logic, as well as provide self-documented, cross-language rules inJSONformat.The focus of this PR is to review its "mechanic" and not completion of its "validation rules" (as it will follow once the mechanic is finalized).
The validation rules are stored in
/data/attribute-validation-rules.json. Originally considered to use YAML (for readability) but decided to go with JSON to minimize hurdles to parse its content on the client-side.TypeScript interface (
interfaces/validation.ts) is available to showcase available rule choices.nullableis required, as it helps separate logics for "empty value" is "not provided".data_typeis required to help provide context to types of rules available to this attribute property.data_typeif you think it may hinder the validation mechanism in golang.The TypeScript implementation response with standardErrorobject. Leaving it as it is for now, but later I would like to explore the option of throwing error with even more context.EDIT:
ValidationErroris now implemented, extends from standardErrorand providing extrapropertyKeyparameter. More custom parameters can be added in the near future if deemed useful.