Chattier guards

[melaniebrgr]

When data fails the validator, it would be nice if the information about the specific guard that failed and the data that it failed with could be optionally surfaced, so, for example, it could be included automatically in logs. This would save time doing manual comparisons of the data with the guards to debug the failure.

(👋 Hi)

[seanmay]

This is a great idea, and one that has been considered.

There are some reasons the library's APIs weren't extended to include messaging.

1. speed / memory usage
   The library is ideally used for validating I/O from servers, databases, (local|session)Storage, IndexedDB, et cetera; because it's a runtime guard, it needs to be pretty lightweight for validating the data types, for, say, a server handling many clients

2. TypeGuards
   Telling people what fails is really handy, but also breaks the TS typeguard, so the API needs to change in order to facilitate error-reporting

3. Flexibility
   To be really useful, it would be good to allow for message customization. If you are customizing tests, then customizing error messages would be equally useful. Another facet of that is security; if one of the pieces you are validating is an email address, or a credit card number, then logging out the string is going to end up causing a lot of trouble.

4. Intent
   Tying the pieces together, I think there are two libraries here; the first is the protection around the I/O as entry points to your system, and the second is a custom validation library with custom messaging, to spit out the paths and the messages of the errors.
   I think that if there were a failure at your data-loading service, you could send your data into a separate process for validation/logging.
   Ideally, I think the second library also supports the same types of test functions to compose over.

I had done a bunch of work on that second library (or second set of functions in the library) in 2018, but at the time, I couldn't get the TypeScript types to turn out the way I wanted, without cheating. Perhaps I should look into that, again.

(also, hi!)

[melaniebrgr]

Good points. Two libraries, one for prod and one for dev, in essence?

[seanmay]

As far as ideology, one would be for guaranteeing correct systems. You can have a completely predictable system, if there is no user input or data; that might not be practical, so likewise, if you guarantee the type of all inputs/user-interactions, you can have a similarly correct system.

The second library could be plugged in for development, but it could also be used for quality control and API logging/debugging. So in a bigger system, you could use the first library to check data coming in, and if there was an API problem, you could send the data to a support endpoint for the back-end team to process. The support endpoint could use the second library to automatically generate a report of broken server responses, with the list of all errors, et cetera.

Likewise, you could use it to return the list of message keys for all errors for each field in form validation, perhaps.
It's would be well-served for when the important pieces are the validation errors, rather than just correctness, with the caveat that it will take longer to run, and will take more space in terms of memory, or the JSON serialized errors.