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

Add object predicate #48

Merged
merged 1 commit into from
Feb 2, 2018
Merged

Add object predicate #48

merged 1 commit into from
Feb 2, 2018

Conversation

SamVerschueren
Copy link
Collaborator

Still work in progress

@SamVerschueren SamVerschueren changed the title [WIP] Add object predicate Add object predicate Feb 1, 2018
@SamVerschueren
Copy link
Collaborator Author

Implemented all of them. One thing I wasn't sure about, is if we should support dot properties with something like dot-prop. This could be nice for the hasKeys and hasAnyKeys.

Somewhat related to the dot properties. Should we support nested objects in valuesOfType as well then?

*
* @param keys The keys that should be present in the object.
*/
hasKeys(...keys: string[]) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make this (and elsewhere) hasAllKeys()? I'm starting to doubt it's clear enough whether it's all keys or any keys if the user hasn't seen hasAnyKeys() yet.

@sindresorhus sindresorhus merged commit 3b570b4 into master Feb 2, 2018
@sindresorhus sindresorhus deleted the object branch February 2, 2018 08:56
@sindresorhus
Copy link
Owner

Looking good :)

@sindresorhus
Copy link
Owner

Implemented all of them. One thing I wasn't sure about, is if we should support dot properties with something like dot-prop. This could be nice for the hasKeys and hasAnyKeys.

Yeah, that could be useful.

Somewhat related to the dot properties. Should we support nested objects in valuesOfType as well then?

What would that look like? I'm not sure I understand.

@SamVerschueren
Copy link
Collaborator Author

What would that look like? I'm not sure I understand.

For instance, this will fail because it only checks the values at root level (Object.keys(input))

const input = {
    foo: 'bar',
    unicorn: {
        rainbow: 'rainbow'
    }
};

ow(input, ow.object.valuesOfType(ow.string));

If we support nested objects, the previous example will succeed.

@sindresorhus
Copy link
Owner

sindresorhus commented Feb 2, 2018

I think that would be surprising behavior by default, but I can see the use-case for it. So, either a deep option to valuesOfType() or a new method valuesOfTypeDeep(). Which do you prefer?

@SamVerschueren
Copy link
Collaborator Author

I think I'm more in favour of valuesOfTypeDeep() because if we start accepting options, it might look weird.

ow(input, ow.object.valuesOfType(ow.string.minLength(4), {deep: true}));

ow(input, ow.object.valuesOfTypeDeep(ow.string.minLength(4)));

It's also in the same fashion as .equal() and .deepEqual().

@sindresorhus
Copy link
Owner

sindresorhus commented Feb 2, 2018

👍 valuesOfTypeDeep()

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 this pull request may close these issues.

2 participants