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
The main context behind it is that there's a defined spec list and a standard pattern to validate that (and the http log). It's a little bit of boilerplate but once it's setup, it provides an easy way to declare what the expected values are, and automatically reject them with a pretty error message if they aren't provided.
Conceptually once we have this documented, we can also review where it's useful throughout the system, and where we can lean into other (new) options for 3rd party validation libraries. For example log_has_error() is used in classes unrelated to API end points
For example,
The text was updated successfully, but these errors were encountered:
one pattern that's throughout the code, that's sort of "good" but not very well documented (which is bad)
is the "regular methods". A more complex example is here https://github.com/diffgram/diffgram/blob/master/default/methods/task/task_template/job_new_or_update.py#L14
Some of the examples and docs is inside the regular side
https://github.com/diffgram/diffgram/blob/master/shared/regular/regular_input.py#L57
The main context behind it is that there's a defined spec list and a standard pattern to validate that (and the http log). It's a little bit of boilerplate but once it's setup, it provides an easy way to declare what the expected values are, and automatically reject them with a pretty error message if they aren't provided.
Conceptually once we have this documented, we can also review where it's useful throughout the system, and where we can lean into other (new) options for 3rd party validation libraries. For example
log_has_error()
is used in classes unrelated to API end pointsFor example,
The text was updated successfully, but these errors were encountered: