moltar/typescript-runtime-type-benchmarks

I don't really quite understand the categories...

dagnelies opened this issue · 2 comments

As far as I understand, all validate the input against a schema and only differ in how they handle extra keys.

  • Loose: extra keys are ignored.
  • Safe: extra keys are removed.
  • Strict: raise an error when input contains extra keys.

In particular, I don't understand the difference between "Strict Parsing" and "Strict Assertion". Isn't it validating the input against a schema and raise an error if it does not strictly match in both cases?

Since it's about "validation", I'm also a bit confused by the "parsing" vs "assertion" terminology.

hoeck commented

Since it's about "validation", I'm also a bit confused by the "parsing" vs "assertion" terminology.

That is about how the API a library provides:

Validation means looking at an object and asserting that it has certain properties:

const unknownData = { /* ... */ }

if (!runtype.test(unknownData)) {
   /* deal with the error */
}

/* now work with unknownData being valid */

Parsing is returning a new valid object to work with:

const unknownData = { /* ... */ }
const validData = runtype.parse(unknownData)

/* now work with validData */

Omitting extra keys without mutation an object in-place only works with a parsing API.

In particular, I don't understand the difference between "Strict Parsing" and "Strict Assertion". Isn't it validating the input against a schema and raise an error if it does not strictly match in both cases?

Some libraries only implement parsing or assertion, so I wanted to have separate benchmarks for that.

And to be fast in both cases, libraries that implement both strict modes must add some additional logic to turn the strict parsing case into a strict assertion.

Looking at it now, it seems kind of redundant, but I hope you got my original motivation for it.

Ok, thanks for the detailed explanation.