-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Joi.string().optional() doesn't treat an empty string as unset #482
Comments
Actually, that work around doesn't work if you've got an additional validation for
This will never actually be allowed to be optional / empty. I really don't want to have to munge the object structure to remove keys that point to empty string values before I pass it into Joi to validate the form data. |
Aren't you looking for |
Not that it matters but it's optional by default, optional is if you want to transform back a joi object that has been |
Oh, I always thought Looks like |
Also, I think the docs may be ambiguous here: https://github.com/hapijs/joi#anyoptional |
The wording seems fine to me, how would you explain it ? |
hmm.. actually, on a second reading, yeah, it does look fine. Would it be an idea to accept empty strings by default and have people explicitly require a length? |
I don't think that's the most common use case. |
Okay, but the other primitives don't put any constrain on values. e.g.,
|
Because of how query strings work. |
hmm, alright, that's a fair case. I guess I can indeed create a custom layer on top of Joi for this, as my use case isn't for an API, but rather a CRUD / Rails style admin panel. |
It's as simple as |
This quite baffled me that |
What do you mean it does not work? |
@WesTyler It does work, but just not the way I would assume it would work. I would expect |
Gotcha. FWIW, For example, you can require a property, but allow it to be an empty string; or you can allow an optional property, but place constraints on it in the case that it exists. That's why presence constraints are separate from content constraints in the schema definitions. |
This confused me too. I thought setting So
Amazingly useful library BTW! 👍 |
@stephen-last If you'd like to take a stab at an update to the docs to clear up the possible confusion we're always glad to review and take action on it. |
@DavidTPate The docs look fine, well, very good actually. This is a well maintained library. I guess I'm just saying that the default behavior of |
Personally I agree that if a string is set as optional, then it shouldn't force a string to be non-empty by default. A perfect example of this is form submission. In the joi schema, optional doesn't mean a form field is optional, as submitting a form sends empty strings for fields it doesn't have. So this forces extra extra explicitness that doesn't feel like it should be necessary to have to add |
The calls for any.optional() and any.required() are quite explicit on this. They define presence requirements, not what the values actually are namely Once the presence requirement is done, then you move on to validation. An empty string is a string. This isn't a truthy/falsey check, if it was then passing We're always glad to take a look at PRs and do our best to help them get merged, feel free to make a PR and see what the community thinks. Personally, I think it is an incorrect change as it removes explicitness that you should have within a validation library. You want to minimize side effects so you can control the input that you accept. |
Hi David, thanks for at least giving it a thought, happy to look into the repo and submit a PR once our holiday crunch is over. I agree with you on two major points you just stated, however I think we have a bit of a disagreement on what exactly that means.
and
To me, The main take away here is that The more that I read over this, |
I'll admit the idea is starting to grow on me, if you're expecting a string it's easy enough to specify a |
Problem: according to its documentation all arguments in Joi are considered optional. This is appearently incorrect, at least for strings. It is currently unknown how to get joi to accept undefined values as acceptable for strings which were meant to be optional arguments. to try this: run `yarn test ./test/paratii.eth.vids.js` to try to get joi to handle undefined strings for `id`, `ipfsHashOrig`, etc. These seemed helpful, but did not fix the problem: - [https://github.com/hapijs/joi/issues/482](https://github.com/hapijs/joi/issues/482) - [https://github.com/hapijs/joi/issues/251](https://github.com/hapijs/joi/issues/251)
joi@12.0.0 is allowing empty from (field.string().allow('').optional()) |
string() not allowing empty strings is absolutely a bug that exists still in JOI 14.
|
You can always open a PR if you feel that strongly about it |
How can you describe an intentional behavior that's been there for years as a bug, let alone a regression? You may not understand or agree with the behavior, but stop depicting it as a bug when it clearly is not. |
Any updates on this? I think this issue should be open. I disagree with @Marsup. I think the inconsistency with how joi.array() behaves alone makes this if not a bug, a much more pressing issue. I am really surprised this hasn't been fixed given how old the issue is. |
This is never going to change. No one is ever going to change my mind on this. It's been like this from day one for a reason. It is not a bug just because it doesn't match your expectations. I am going to add a big notice in the docs saying "empty strings are not valid strings, use |
I thinks |
@shonubijery are you looking for optional pass...if yes, then try joi.string().optional() |
I still find this all a bit silly. This still trips me up every few months after not using Joi for a while. |
Still arguing about this is what's silly. |
I'm hitting into this when creating Joi schemas for forms, where I have a text input which can optionally be filled in, but if it's not, then no problems.
At the moment I have to use the work around of:
This is due to this line: https://github.com/hapijs/joi/blob/master/lib/string.js#L19
I'd be inclined to argue that if you've just said
Joi.string()
without any optional or required tags, then an empty string is actually a valid value. If you say it's required, then an empty string would be invalid.Thoughts?
The text was updated successfully, but these errors were encountered: