Schema testing against an object that extends the schema about v8n HOT 10 CLOSED

Yes, this is intended. It works much like an interface would validate a class if you will. Imagine simple interface.

interface Animal {
  name: string;
}

class Dog implements Animal {
  name: string;
  race: string;
}

A lot of classes could be made from this, they only need to implement what is there. That's how interfaces usually work and that is how schema works.

I guess an exact schema validation may be an interesting thing. Gotta ask @imbrn what he thinks.

from v8n.

Hey guys, how's it going?

So @dbismut, as @brfrth explained, the schema acts most like an interface, so the intention is indeed to validate extended objects. But I liked the idea of having a strict mode for that. If you guys agree, I think we should go with the modifier based version.

from v8n.

Ok! Just to explain my usecase, I'm in a situation where I want to detect the schema of an object. To do so I'm testing the object against a list of schemas. First schema from the list that matches the object is the one.

My problem comes as one schema is Point2d {x,y} and another is Point3d {x,y,z}. You see me coming but if Point2d is tested before Point3d, all {x,y,z} objects will be marked as Point2d.

It's no big deal as in my case I just need to test Point3d before Point2d but I was curious to know if I was missing something.

from v8n.

I get the idea of an exact schema validation for multiple use cases. Worth discussing.

from v8n.

I guess checking if the number of keys are equal would suffice?

from v8n.

I guess so. You can add it if you want and pull request.

from v8n.

I'm just not sure about the api though? schema().strict()?

from v8n.

Why not add an optional argument to schema?

function schema(schema, strict = false) {
  // ...
}

Strict would be a modifier if anything, meaning it would be chained the other way.

v8n()
  .strict.schema({})
  .test({});

I honestly like both. The modifier is harder to implement though a tad more elegant.

from v8n.

Oh I agree.

Plus if strict is set, we should first check if the number of keys are equal and skip further validation if not. That's probably faster to check negatives than with chaining strict.

from v8n.

Closing this in favor of #191, thanks for your idea and input.

from v8n.