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

Nullable modifier #163

Open
Riim opened this issue Oct 19, 2019 · 8 comments
Open

Nullable modifier #163

Riim opened this issue Oct 19, 2019 · 8 comments

Comments

@Riim
Copy link

Riim commented Oct 19, 2019

ow.nullable.string
instead of
ow.any(ow.string, ow.null)

A generic modifier for |null|undefined would also be useful. Maybe it is better if optional will also allow null? In most cases, you need |null|undefined and |null. Separately, |undefined is needed almost never.

@sindresorhus
Copy link
Owner

We are unlikely to add this as we feel null should not be used in general. See: sindresorhus/meta#7

@Riim
Copy link
Author

Riim commented Oct 20, 2019

  1. It is not always possible to refuse null. For example, I check the server response and GraphQL really likes to send null. My server developer are unlikely to be inspired by the idea of abandoning null.
  2. Sometimes it is possible to use null to your advantage. Example: undefined - data was not requested from server, null - requested, there is no data. This works great for me.
  3. It is unlikely that more than 5-10 lines of code (without tests) will be required to implement this; this is really a simple functionality.

@mnmkng
Copy link

mnmkng commented Oct 21, 2019

I'd also like to support the idea of having a nullable validator. Even though I generally agree with sindresorhus/meta#7, null is out there in the wild and since dynamic type-checks mostly exist for validating input that is provided at runtime, I feel that we can't just discount null on the basis of code-style preference.

Originally, I wanted to submit an issue to discuss standardization of exception messages, but having a nullable validator that'd merge the message would work as well.

Current:

ArgumentError: Any predicate failed with the following errors:
- Expected property `foo` to be of type `null` but received type `Object`
- Expected `foo` to be of type `number` but received type `Object` in object

Preferred:

ArgumentError: Expected property `foo` to be of type `number` or `null` but received type `Object`

@Riim
Copy link
Author

Riim commented Oct 21, 2019

Sorry for my english and my persistence.

Why not use the following syntax instead of any:

ow.number.or.string;

?
This allows you not to break your fingers once again by typing brackets and solves the problem with null:

ow.number.or.null;
ow.number.or.null.or.undefined;

It is also not clear why need the types for int8Array, uint8Array, nan, etc.? Such libraries are usually used at the junction of code bases. Like the following:

  1. The client part of the application receives data from the server and checks this data for changes in the API.
  2. On the contrary: the server checks the incoming parameters to immediately stop processing the request if the parameters are incorrect.
  3. Data is validated before being sent to the database, for example, in my ORM joi is used for this.

In all the above examples, no int8Array is possible. Maybe for smaller size it's better to limit types to possible in json plus undefined and maybe some commonly used types?

UPDATE:
I suddenly read the first line in readme and realized why ow is what it is. It's just for other tasks. This is the fourth attempt to find a validation library suitable for my tasks. Before that there were type-check, joi, yup. Looks like I'll have to write it himself ((.

UPDATE2: Probably a bit crude implementation, but already quite working: @riim/type.

@sindresorhus
Copy link
Owner

sindresorhus commented Nov 12, 2019

I have changed my mind. It does indeed make sense to add this here as you can't control what other APIs use. PR welcome.

I still want a link to sindresorhus/meta#7 in the docs to try to convince people to not use null in their own APIs though.

@sindresorhus
Copy link
Owner

I wanted to submit an issue to discuss standardization of exception messages

You should still open an issue about this for other use-cases. We've tried to keep the messages consistent, but I'm sure we missed some cases.

@sindresorhus
Copy link
Owner

Why not use the following syntax instead of any:
ow.number.or.string;

I don't remember exactly why we didn't do it this way. It does look nice, but there are ambiguous cases:

ow.string.length(3).and.string.uppercase.or.string.includes('f')

Does this mean it accepts
(ow.string.length(3) && string.uppercase) || string.includes('f')
or
(ow.string.length(3) && (string.uppercase || string.includes('f'))
?

@Riim
Copy link
Author

Riim commented Nov 12, 2019

In omyumyum i use .custom() to transfer priority to .or. For example, an object may contain either a field age or field birthday:

om.object.shape({ name: om.string }).and.custom(
  om.object.shape({ age: om.number })
    .or.object.shape({ birthday: om.date })]
);

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

No branches or pull requests

3 participants