docs: links to issues
Evgeny Poberezkin
parent
e9f6896582
commit
8667e3caf2
18
FAQ.md
18
FAQ.md
|
|
@ -5,52 +5,54 @@ The purpose of this document is to help find answers quicker. I am happy to cont
|
|||
|
||||
## Ajv API for returning validation errors
|
||||
|
||||
See #65, #212, #236, #242, #256.
|
||||
See [#65](https://github.com/epoberezkin/ajv/issues/65), [#212](https://github.com/epoberezkin/ajv/issues/212), [#236](https://github.com/epoberezkin/ajv/issues/236), [#242](https://github.com/epoberezkin/ajv/issues/242), [#256](https://github.com/epoberezkin/ajv/issues/256).
|
||||
|
||||
|
||||
#### Why Ajv assigns errors as a property of validation function (or instance) instead of returning an object with validation results and errors?
|
||||
##### Why Ajv assigns errors as a property of validation function (or instance) instead of returning an object with validation results and errors?
|
||||
|
||||
The reasons are history (other fast validators with the same api) and performance (returning boolean is faster). Although more code is written to process errors than to handle successful results, almost all server-side validations pass. The existing API is more efficient from the performance point of view.
|
||||
|
||||
Ajv also supports asynchronous validation (with custom asynchronous formats and keywords) that returns a promise that either resolves to `true` or rejects with an error.
|
||||
|
||||
|
||||
#### Would errors get overwritten in case of "concurrent" validations?
|
||||
##### Would errors get overwritten in case of "concurrent" validations?
|
||||
|
||||
No. There is no concurrency in JavaScript - it is single-threaded. While a validation is run no other JavaScript code (that can access the same memory) can be executed. As long as the errors are used in the same execution block, the errors will not be overwritten.
|
||||
|
||||
|
||||
#### Can we change / extend API to add a method that would return errors (rather than assign them to `errors` property)?
|
||||
##### Can we change / extend API to add a method that would return errors (rather than assign them to `errors` property)?
|
||||
|
||||
No. In many cases there is a module responsible for the validation in the application, usually to load schemas and to process errors. This module is the right place to introduce any custom API. Convenience is a subjective thing, changing or extending API purely because of convenience would either break backward compatibility (even if it's done in a new major version it still complicates migration) or bloat API (making it more difficult to maintain).
|
||||
|
||||
|
||||
## Additional properties inside compound keywords anyOf, oneOf, etc.
|
||||
|
||||
See #127, #129, #134, #140, #193, #205, #238, #264.
|
||||
See [#127](https://github.com/epoberezkin/ajv/issues/127), [#129](https://github.com/epoberezkin/ajv/issues/129), [#134](https://github.com/epoberezkin/ajv/issues/134), [#140](https://github.com/epoberezkin/ajv/issues/140), [#193](https://github.com/epoberezkin/ajv/issues/193), [#205](https://github.com/epoberezkin/ajv/issues/205), [#238](https://github.com/epoberezkin/ajv/issues/238), [#264](https://github.com/epoberezkin/ajv/issues/264).
|
||||
|
||||
|
||||
#### Why the keyword `additionalProperties: false` fails validation when some properties are "declared" inside a subschema in `anyOf`/etc.?
|
||||
##### Why the keyword `additionalProperties: false` fails validation when some properties are "declared" inside a subschema in `anyOf`/etc.?
|
||||
|
||||
The keyword `additionalProperties` creates the restriction on validated data based on its own value (`false` or schema object) and on the keywords `properties` and `patternProperties` in the SAME schema object. JSON-schema validators must NOT take into account properties used in other schema objects.
|
||||
|
||||
While you can expect that the schema below would allow the objects either with properties `foo` and `bar` or with properties `foo` and `baz` and all other properties will be prohibited, this schema will only allow objects with one property `foo` (an empty object and any non-objects will also be valid):
|
||||
|
||||
```json
|
||||
{
|
||||
"properties": { "foo": { "type": "number" } },
|
||||
"additionalProperties": false,
|
||||
"oneOf": [
|
||||
{ "properties": { "bar": { "type": "number" } } },
|
||||
{ "properties": { "baz": { "type": "number" } } }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
The reason for that is that `additionalProperties` keyword ignores properties inside `oneOf` keyword subschemas. That's not the limitation of Ajv or any other validator, that's how it must work according to the standard (and if you consider all the problems with the alternatives it is the only sensible way to define this keyword).
|
||||
|
||||
There are several ways to implement the logic that is expected, please see the suggestions in the issues mentioned above.
|
||||
There are several ways to implement the described logic that would allow two properties, please see the suggestions in the issues mentioned above.
|
||||
|
||||
|
||||
#### Why the validation fails when I use option `removeAdditional` with the keyword `anyOf`/etc.?
|
||||
##### Why the validation fails when I use option `removeAdditional` with the keyword `anyOf`/etc.?
|
||||
|
||||
This problem is related to the problem explained above - properties treated as additional in the sence of `additionalProperties` keyword, based on `properties`/`patternProperties` keyword in the same schema object.
|
||||
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ Ajv is tested with these browsers:
|
|||
|
||||
[](https://saucelabs.com/u/epoberezkin)
|
||||
|
||||
__Please note__: some frameworks, e.g. Dojo, may redifine global require in such way that is not compatible with CommonJS module format. In such case Ajv bundle has to be loaded before the framework and then you can use global Ajv (see issue #234).
|
||||
__Please note__: some frameworks, e.g. Dojo, may redifine global require in such way that is not compatible with CommonJS module format. In such case Ajv bundle has to be loaded before the framework and then you can use global Ajv (see issue [#234](https://github.com/epoberezkin/ajv/issues/234)).
|
||||
|
||||
|
||||
## Command line interface
|
||||
|
|
@ -541,7 +541,7 @@ The intention of the schema above is to allow objects with either the string pro
|
|||
|
||||
With the option `removeAdditional: true` the validation will pass for the object `{ "foo": "abc"}` but will fail for the object `{"bar": 1}`. It happens because while the first subschema in `oneOf` is validated, the property `bar` is removed because it is an additional property according to the standard (because it is not included in `properties` keyword in the same schema).
|
||||
|
||||
While this behaviour is unexpected (issues #129, #134), it is correct. To have the expected behaviour (both objects are allowed and additional properties are removed) the schema has to be refactored in this way:
|
||||
While this behaviour is unexpected (issues [#129](https://github.com/epoberezkin/ajv/issues/129), [#134](https://github.com/epoberezkin/ajv/issues/134)), it is correct. To have the expected behaviour (both objects are allowed and additional properties are removed) the schema has to be refactored in this way:
|
||||
|
||||
```JSON
|
||||
{
|
||||
|
|
@ -643,7 +643,7 @@ console.log(data2); // { foo: { bar: 2 } }
|
|||
`default` keywords in other cases are ignored:
|
||||
|
||||
- not in `properties` or `items` subschemas
|
||||
- in schemas inside `anyOf`, `oneOf` and `not` (see #42)
|
||||
- in schemas inside `anyOf`, `oneOf` and `not` (see [#42](https://github.com/epoberezkin/ajv/issues/42))
|
||||
- in `if` subschema of v5 `switch` keyword
|
||||
- in schemas generated by custom macro keywords
|
||||
|
||||
|
|
@ -968,7 +968,7 @@ Defaults:
|
|||
- _passContext_: pass validation context to custom keyword functions. If this option is `true` and you pass some context to the compiled validation function with `validate.call(context, data)`, the `context` will be available as `this` in your custom keywords. By default `this` is Ajv instance.
|
||||
- _loopRequired_: by default `required` keyword is compiled into a single expression (or a sequence of statements in `allErrors` mode). In case of a very large number of properties in this keyword it may result in a very big validation function. Pass integer to set the number of properties above which `required` keyword will be validated in a loop - smaller validation function size but also worse performance.
|
||||
- _ownProperties_: by default ajv iterates over all enumerable object properties; when this option is `true` only own enumerable object properties (i.e. found directly on the object rather than on its prototype) are iterated. Contributed by @mbroadst.
|
||||
- _multipleOfPrecision_: by default `multipleOf` keyword is validated by comparing the result of division with parseInt() of that result. It works for dividers that are bigger than 1. For small dividers such as 0.01 the result of the division is usually not integer (even when it should be integer, see issue #84). If you need to use fractional dividers set this option to some positive integer N to have `multipleOf` validated using this formula: `Math.abs(Math.round(division) - division) < 1e-N` (it is slower but allows for float arithmetics deviations).
|
||||
- _multipleOfPrecision_: by default `multipleOf` keyword is validated by comparing the result of division with parseInt() of that result. It works for dividers that are bigger than 1. For small dividers such as 0.01 the result of the division is usually not integer (even when it should be integer, see issue [#84](https://github.com/epoberezkin/ajv/issues/84)). If you need to use fractional dividers set this option to some positive integer N to have `multipleOf` validated using this formula: `Math.abs(Math.round(division) - division) < 1e-N` (it is slower but allows for float arithmetics deviations).
|
||||
- _errorDataPath_: set `dataPath` to point to 'object' (default) or to 'property' (default behavior in versions before 2.0) when validating keywords `required`, `additionalProperties` and `dependencies`.
|
||||
- _messages_: Include human-readable messages in errors. `true` by default. `false` can be passed when custom messages are used (e.g. with [ajv-i18n](https://github.com/epoberezkin/ajv-i18n)).
|
||||
- _beautify_: format the generated function with [js-beautify](https://github.com/beautify-web/js-beautify) (the validating function is generated without line-breaks). `npm install js-beautify` to use this option. `true` or js-beautify options can be passed.
|
||||
|
|
|
|||
Loading…
Reference in New Issue