Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Additional joi validation #65

Open
maldimirov opened this issue Nov 23, 2018 · 4 comments
Open

[Feature] Additional joi validation #65

maldimirov opened this issue Nov 23, 2018 · 4 comments

Comments

@maldimirov
Copy link
Contributor

Description:
Would you consider a PR for the ability to add additional Joi validation to the converted schemas?
Joi supports this using schema concatenation. So it will be something like:

resolve(schema = this.root, joiSchema = this.additionalValidation) {
    if (schema.type) {
        return joiSchema ?
            this.resolveType(schema).concat(joiSchema) :
            this.resolveType(schema);
    }
...

This will give great flexibility to Enjoi by enabling the use of the full potential of Joi.

Background:
In our project we need to have more precise validation than what JSON Schema provides. E.g. for dates we want not only to match the YYYY-MM-DD format from RFC3339 Section 5.6, but also apply the restrictions from Section 5.7 - forbid the 31st day for Feb, Apr, etc.

@tlivings
Copy link
Owner

Could you not do this by simply using refineType with a more custom format ?

@maldimirov
Copy link
Contributor Author

You are right. It can be done using refineType and a custom type. The only downside I see to this is that you need to recreate the same joi validation schema as what enjoi already provides and then add the extra needed validation on top of it. Which is not a deal breaker, just a note.

So, we will probably go with refineType. But as the PR was almost ready if you still think an addition like the suggested one would add value to enjoi I will be happy to finish the code.

@tlivings
Copy link
Owner

You can also use the extensions feature. That might behave more like you are wanting because you can fully extend joi that way.

I’m happy to look at a PR still. Depending on how it fits in with the theme of enjoi I don’t see an issue with accepting such a change.

@maldimirov
Copy link
Contributor Author

The PR is ready.
This functionality would be more viable than refineType in the cases where you want to change the default validation per instance, not globally for a specified type. Also e.g. for objects you can add boolean logic rules between the keys/properties of the object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants