Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

isShape validator and better documentation generation #183

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

dlmr
Copy link
Member

@dlmr dlmr commented Jun 20, 2017

Adds a new validator that can be used most specifically for Hook validation.

This PR also improves the information in the documentation generation for isArray, isObject and oneOf validators giving information about the types that they wrap.

This through a new syntax for the documentation generation when describing wrapped validators. [TYPE] means that the type is optional, <TYPE> means that it is required. A question mark in front of the type, ?TYPE means that it can be empty.

Array(<String>) means that null and undefined are allowed as values but not empty strings as an example.

dlmr added 4 commits June 20, 2017 14:08
Added extra arguments to the wrapper function to be able to describe
what is required and can't be empty along with a helper for formatting
that information.
This makes processResult work better with isShape.
@dlmr dlmr added the feature label Jun 20, 2017
*/
export default function writeInfoInline(type, canBeEmpty, required) {
const empty = canBeEmpty ? '?' : '';
return type && `${required ? `<${empty}${type}>` : `[${empty}${type}]`}`;

Choose a reason for hiding this comment

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

Do we want to force this to always return a string? Right now it'll return a falsy value or a string

Copy link
Member Author

Choose a reason for hiding this comment

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

The idea is that type will only ever be the empty string, and because of that we will return the empty string. Could be discussed if it would be better to not have such implicit assumptions.

key: `${key}`,
value: input[key],
message: result,
};

Choose a reason for hiding this comment

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

Would there be any way to create a composed validation error of all properties that failed to validate?

Copy link
Member Author

Choose a reason for hiding this comment

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

The idea is to both fail early and to not overwhelm the user with error messages.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants