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

Make certain rules override themselves #1127

Closed
dwelle opened this issue Mar 17, 2017 · 5 comments
Closed

Make certain rules override themselves #1127

dwelle opened this issue Mar 17, 2017 · 5 comments
Assignees
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Milestone

Comments

@dwelle
Copy link
Contributor

dwelle commented Mar 17, 2017

Context

  • joi version: 10.2.2

What are you trying to achieve or the steps to reproduce ?

Currently, calling e.g. .min() multiple times just accumulates the rules (as it should), but in this case it doesn't make sense.

Suppose I have a library of schemas, and the default for some array is .min(1).. if I want to re-use the schema but override it to allow 0 members, I can't AFAIK.

Joi.array().min(0).min(1)

should IMO override the 0 with 1.

I understand that for some rules it'd be hard to determine what should override what -- particularly when trying to override one rule with a different one (e.g. min(1).allow([])), but I think that it might not be hard to specify a list of rules which override themselves (min, max etc.).

Thoughts?

@WesTyler
Copy link
Contributor

I think this is where "prototyping" your schema carefully can negate this potentially-messy feature.

const baseArray = Joi.array();
const min1 = baseArray.min(1);
const min0 = baseArray.min(0);

I know that's more to keep up, but if you're using a library of schemas I don't think this would increase your maintenance overhead too much more.

@Marsup Marsup added the request label Mar 17, 2017
@Marsup
Copy link
Collaborator

Marsup commented Mar 17, 2017

This is not completely far fetched, since a few rules already do that. Indeed better designing your schemas is a solution but I'm not against supporting this.

@dwelle
Copy link
Contributor Author

dwelle commented Mar 18, 2017

Alright, we can let it sit here for a while to see if more people want this, and I can later try to issue a PR if it won't turn out crazy complex.

Meanwhile, do the following examples fall under this request, or should it be considered a bug?

Joi.object().unknown( false );
Joi.object().options({ allowUnknown: false });

Both of which allow unknown (I'm aware that's the behavior of .object()), which is IMO unintuitive and again makes it harder to create schema libraries, or to enforce global options.

I.e. it easily allows to create unintended consequences that could become security issues.

@Marsup
Copy link
Collaborator

Marsup commented Mar 18, 2017

Options are transmitted down while flags are local, flags should probably always win so there's nothing to fix here. I'd limit the scope of this PR to what's local.

@Marsup Marsup added this to the 14.0.0 milestone Aug 3, 2018
@Marsup Marsup added the breaking changes Change that can breaking existing code label Aug 3, 2018
@Marsup Marsup self-assigned this Aug 3, 2018
@Marsup Marsup closed this as completed in 674a59e Oct 14, 2018
@hueniverse hueniverse added feature New functionality or improvement and removed request labels Sep 19, 2019
@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

4 participants