Validator ideas

[sindresorhus]

Validator ideas

[sindresorhus]

Great! I was actually going to open this exact issue yesterday, but got busy. I've been having this draft for a while:

all

• optional (Means undefined is allowed) (Note: I don't think we should allow null, to align with default parameters)
• not (Inverts the following predicates)
• not(type) (Inverts just the argument) (Example: ow.string.not(ow.empty))
• any (For multiple predicates, for example, when something can be both a string and array)
• is(function) (Accepts a function that receives the value from ow and is expected to return a boolean)

string

• length(number)
• minLength(number)
• maxLength(number)
• match(regex: RegExp) (Seems like matches would better align with other names like includes, startsWidth?)
• startsWith(string)
• endsWith(string)
• includes(string)
• empty (Only useful when used with .not)
• nonEmpty
• equal(string)
• alphanumeric
• numeric
• date

number

• inRange(start: number, end: number)
• integer
• equal(number)
• positive
• negative
• finite
• min(number)
• max(number)

boolean

• true
• false

array

• ofType(type, …) (Accepts any is.x type) (TODO: Would be useful if this could also support any ow predicate for each element, so you could do: ow.array.ofType(ow.string.minLength(5)))
• length(number)
• minLength(number)
• maxLength(number)
• startsWith(string)
• endsWith(string)
• includes(string, …)
• includesAny(string, …)
• empty (Only useful when used with .not)
• nonEmpty
• deepEqual(array)

object

• valuesOfType(type, …) (Accepts any is.x type)
• plain
• empty (Only useful when used with .not)
• nonEmpty
• deepEqual(object)
• instanceOf(object)
• hasKeys(property, …)
• hasAnyKeys(property, …)

date

• before(date)
• after(date)

error

• evalError
• rangeError
• referenceError
• syntaxError
• typeError
• uriError
• name(string)
• message(string)
• messageIncludes(string)

map

• size(number)
• minSize(number)
• maxSize(number)
• keysOfType(type, …)
• valuesOfType(type, …)
• hasKeys(string, …)
• hasValues(string, …)
• hasAnyKeys(string, …)
• hasAnyValues(string, …)
• empty (Only useful when used with .not)
• nonEmpty
• deepEqual(map)

set

• size(number)
• minSize(number)
• maxSize(number)
• ofType(type, …)
• has(string, …)
• hasAny(string, …)
• empty (Only useful when used with .not)
• nonEmpty
• deepEqual(set)

weakMap

• keysOfType(type, …)
• hasKeys(string, …)
• hasAnyKeys(string, …)

weakSet

• ofType(type, …)
• has(string, …)
• hasAny(string, …)

undefined

null

symbol

function

buffer

regExp

promise

typedArray

int8Array(value)

uint8Array(value)

uint8ClampedArray(value)

int16Array(value)

uint16Array(value)

int32Array(value)

uint32Array(value)

float32Array(value)

float64Array(value)

arrayBuffer(value)

sharedArrayBuffer(value)

dataView(value)

nan(value)

nullOrUndefined(value)

iterable(value)

---

gt(value: number)
lt(value: number)

I think min and max is clearer and more readable. What do you think?

float (number-is-float)

I don't really see the point of float. 1 could be a float too. I don't see the value of differentiating it. integer, however, could be useful, for when you only accept whole numbers.

negativeZero (negative-zero)
positiveZero (positive-zero)

I've honestly never needed this. Let's skip it until there are actual valid needs.

[SamVerschueren]

I don't really see the point of float

Never needed it. Was just going through @kevva and your packages to see what we could use :).

I've honestly never needed this. Let's skip it until there are actual valid needs.

👌 Me neither.

I think min and max is clearer and more readable.

I'm fine with both. I might have a slight preference for gt and lt because I feel it reads easier.

ow(5, ow.number.gt(4));
//=> 5 should be a number greater than 4

ow(5, ow.number.min(4));
//=> 5 should be a number with a minimum of 4

---

One thing I thought about as well is to have an is predicate on every type which accepts a function. This could keep ow lighter with less built-in dependencies.

const ow = require('ow');
const inRange = require('in-range');
const validDate = require('vali-date');
const positive = require('is-positive');

ow(5, ow.number.is(positive).is(x => inRange(x, 0, 10));

ow('2017-05-21', ow.string.is(validDate));

It's just an example though, I think having things like positive and inRange in ow itself would be very nice. The is method could be just an extra which allows people to easily extend it.

[sindresorhus]

One thing I thought about as well is to have an is predicate on every type which accepts a function.

Good idea! I agree it would be useful. I've added it to the proposal.

[sindresorhus]

I'm fine with both. I might have a slight preference for gt and lt because I feel it reads easier.

I agree. It shows the intent better, and ow is all about adding readability. I think it should be greaterThan instead of gt though.

[SamVerschueren]

Thinking about it, I believe min and greaterThan are not identical.

min: value >= x
greaterThan: value > x

The intent of greaterThan might be clearer, because with min, users might not be sure if x is included or excluded. But don't think it justifies that we should implement both.

[sindresorhus]

Thinking about it, I believe min and greaterThan are not identical.

I never implied they were.

But don't think it justifies that we should implement both.

I think it does. There's a reason we have both > and >= in most programming languages. It also makes the error message better.

[sindresorhus]

But maybe min should be greaterThanOrEqual? For consistency? I dunno.

[SamVerschueren]

So we should add greaterThan and greaterThanOrEqual right?

[sindresorhus]

That's my suggestion, yes. The latter is a bit verbose but good for readability, and better than min for consistency.

[SamVerschueren]

Good idea! Added!

[SamVerschueren]

We're almost done with this list, so I was looking into the ones that we didn't implement yet. I have a question regarding optional

optional (Means undefined is allowed) (Note: I don't think we should allow null, to align with default parameters)

Should it be

ow(x, ow.optional.string.minLength(4));

// or

ow(x, ow.string.optional.minLength(4));

Or both of course.

If we go for either 2 or 3 (both), this mean we could write something like ow.string.minLength(4).optional.maxLength(5) which doesn't really make sense. That's why I'm more in favour of 1.

[sindresorhus]

Lets go with 1

[sindresorhus]

notType(type) (Inverts just the argument) (Example: ow.string.notType(ow.empty))

I think it's better to just do #71

[sindresorhus]

Closing as we've done all of these. Wow!