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

Fixed confusing prop selector behavior. Added helpful warning #130

Merged
merged 1 commit into from
Jan 20, 2016

Conversation

lelandrichardson
Copy link
Collaborator

to: @lencioni @ljharb @blainekasten

When users were passing in selectors with a non-quoted string such as [type=foo] it was causing undesired behavior, matching any component that had the type prop. This refactors the logic so that if the string is unquoted (and not an acceptable numeric literal or boolean), we throw a helpful error indicating that it should be quoted.

Fixes #127; Closes #129

if (propValue === 'false') return false;

// user provided an unquoted string value
throw new Error(
Copy link
Member

Choose a reason for hiding this comment

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

this should probably be a TypeError

Copy link
Contributor

Choose a reason for hiding this comment

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

I also like what's going on this PR with prefacing these errors with Enzyme::Selector

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

👍 i know, i know. my laziness is getting the best of me.

@lelandrichardson lelandrichardson force-pushed the lmr--fix-prop-selector-string-issue branch from 1840e29 to 0033fbf Compare January 20, 2016 20:35
@lencioni
Copy link
Contributor

👍

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

Successfully merging this pull request may close these issues.

4 participants