Providing Context to Type Functions

[ianstormtaylor]

Providing Context to Type Functions

[ianstormtaylor]

Hey @simplygreatwork, good question!

Do you have an example of the struct your are validating with? And what the data looks like?

[simplygreatwork]

In the superstruct docs, the age type example had bounds embedded inside the type function. I would like to be able to validate bounds from a schema.

YAML schema

---
  type: Person
  properties:
    age:
      type: 'number?'
      range: [18, 120]

To do this currently, I am using struct.intersection to compose the number type with struct.function to do the bounds checking. I think this is the correct approach for now even if struct.function is an escape hatch.

var config = {};
var properties = schema.properties;
for (var key in properties) {
    var object = properties[key];
    config[key] = object.type;
    if (object.range) {
        config[key] = struct.intersection([config[key], struct.function(function(value) {
            return (value >= object.range[0]) && (value <= object.range[1]);
        })]);
    }
}
var Person = struct(config);

But an alternative could be for type functions to be passed a second argument, the key of the property being validated.

types : {
    age : function(value, key) {
        if (this.properties[key].range) {
            var range = this.properties[key].range;
            return (value >= range[0]) && (value <= range[1]);
        }
    }.bind(schema)      // binding a schema definition to become "this" above
}

Let me know if you want me to express this in more detail. I'm mainly observing that values are passed into type functions - without any other context. But maybe they would no longer be type functions - they would be validation functions.

[ianstormtaylor]

@simplygreatwork I'm not sure what the this.properties piece is there? Or how the range itself is being passed in? Could you try writing up the struct definition with the current API but with your tweak applied? I think bridging the gap from YAML to JS is confusing me.

What I'd recommend though is actually treating "age" as a type itself, where it has a fixed range of 18–120 or whatever makes sense for your application's problem space.

[simplygreatwork]

You don't need to change anything in superstruct. It is super rad as it is. I'm OK with using struct.function. Above, this.properties is actually schema.properties because I used the bind keyword to bind schema to this. schema.properties is just an associative array of objects defining properties of my schema.

In superstruct, I do love that I can create new high-level types. That works great when superstruct and JavaScript are the single source of truth for my system. But if a YAML document is my single source of truth across multiple programming languages, then implementing number bounds checking is more low level or portable than validating an age type in multiple programming languages.

I was mainly proposing that you consider passing a second argument to each type function: the key of the property being validated.