I'm not sure how to integrate the typescript definitions with the microbundle build process, help wanted :)

This library would be very cool for APIs that need parameter check, with Typescript. I am planning to implement this soon.

This might require a rewrite

By piggybacking onto the API suggested here we could easily define a methodology for converting data into Binary. We could also take advantage of the type information in the format to create significant size reductions. For example we could account for custom string character sets (like only ASCII or a-z or lowercase etc) in order to represent the data in less bits. By doing this we could create a BSON like encoding that largely doesn't need any type information at all, and it can be optimized at compile time so we can create lightning fast binary serializers.

We could take a format here

[{_: Number, {min: 0, max: 16}]

Here we know at compile time we can represent this number using only 4 bits (2^4=16). The only dynamic part here would be the array length itself.

Before our encoder maybe it was in JSON which requires either a ton of Unicode (very wasteful) or BSON (pretty slow and can't optimize based on the data structure to my knowledge), or using a custom serializer which is generally very time consuming and error-prone.

I probably won't implement this, however if this is an issue for people feel free to comment or even better make a pull request

As the valid method behavior has changed to throw errors instead of return true/false the documentation will need to be updated.

This is proving difficult to implement however I should figure it out sometime in the unknown future.

{ _: ["Property Missing"], a: ["Invalid Type"] } seems a bad way to handle errors. What about throwing an error instead?

Add support for sanitizing a data input as a function

See "lower" and "upper" in docs. It should be "lowercase" and "uppercase" instead

We could create our own file extension for formats, then when the user imports that file they get a file containing a bunch of "hand-optimized" functions for data sanitation.

How do our type checks become hand-optimized?

Well lowerString.sand.js

{_: String, lowercase: true}

becomes

export function sanitize(data) {
      if (typeof data != 'string') throw new Error("Data is not a string")
}
// ... and more methods (we could actually split them into multiple files at build time for tree-shaking possibly but this is an implementation details)

This could have a massive performance payoff as it prevents us from needing to parse and recursively traverse the format at run-time. Instead we can let the formats define their own source code using some kind of API standard. It also can save significant amounts of time for formats which have a lot of possible options.

{
    symbol: String,
    validate: ['typeof data != "string"', 'Expected a string'],
    options: {
        lowercase: ['data !== data.toLowerCase())', 'String must be lowercase']
    }
 }
 // Note the "array of strings" syntax makes it easy for us to compile our functions differentially

One downside is this wouldn't have good support for contexts, but arguably that's a good thing in most cases, but it could still be limiting for specific use cases, and push people towards doing global stuff. We might benefit users by making the compilation step completely optional for end-users.

Edit: We should also support nested formats which means using import order to re-assemble the format structures

Upon further it seems like ClojureScript's macro features might be the best target for optimizing Sandhand's performance. I'm going to focus on targeting ClojureScript over rust for now.