The schema API we have been using seems as if it was an afterthought by the express-validators development team. It is missing documentation, and the developers admit that some critical functionality is just not available through this API.
Motivation
Mainly, we need the oneOf feature linked above, for any form field or collection of fields which may have more than one validation shape. Our example from the passport application was a height parameter which could be measured in ft/in or in cm. In order to specify that one of them had to be present but the other should be blank, we had to resort to a custom validator, circumventing most of the express-validator machinery.
Design Detail
It may be as simple as exporting a middleware from ./schema.js using the express-validator API.
Drawbacks
Prior Art
There has been some discussion of using JSON Schema - in my cursory research on this, it seemed as if JSON Schema was more geared towards having a static data structure (its own language, in a sense) that described the data. While very flexible, if we were to come across something not supported by JSON Schema we would not be able to do validation at all. Express-validator, on the other hand, allows us to use plain javascript functions to cover any corner cases not covered by the DSL. To me, this seems a little more future-proof.
Unresolved questions
We are currently using the schema for things like default values (which is actually causing warnings) and for selecting which keys we load from the session/body. I would suggest either moving these responsibilities to presenters, or using loadFullSession() and a new loadFullBody() to make sure all keys are loaded by default.
Summary
The schema API we have been using seems as if it was an afterthought by the express-validators development team. It is missing documentation, and the developers admit that some critical functionality is just not available through this API.
Motivation
Mainly, we need the
oneOffeature linked above, for any form field or collection of fields which may have more than one validation shape. Our example from the passport application was a height parameter which could be measured in ft/in or in cm. In order to specify that one of them had to be present but the other should be blank, we had to resort to a custom validator, circumventing most of the express-validator machinery.Design Detail
It may be as simple as exporting a middleware from
./schema.jsusing the express-validator API.Drawbacks
Prior Art
There has been some discussion of using JSON Schema - in my cursory research on this, it seemed as if JSON Schema was more geared towards having a static data structure (its own language, in a sense) that described the data. While very flexible, if we were to come across something not supported by JSON Schema we would not be able to do validation at all. Express-validator, on the other hand, allows us to use plain javascript functions to cover any corner cases not covered by the DSL. To me, this seems a little more future-proof.
Unresolved questions
We are currently using the schema for things like default values (which is actually causing warnings) and for selecting which keys we load from the session/body. I would suggest either moving these responsibilities to presenters, or using
loadFullSession()and a newloadFullBody()to make sure all keys are loaded by default.