Support Property Selector #70

blainekasten · 2015-12-12T18:20:37Z

Per discussion in #4 and continued discussion here. This PR adds support for querying react properties, and not html attributes. The following syntax works:

component.find('input[type="text"][value="1"])
component.find('label[htmlFor="button"]')
component.find('div[data-wrapper]')

goatslacker · 2015-12-12T18:46:45Z

src/Utils.js

@@ -128,3 +136,46 @@ export function AND(fns) {
 return true;
 };
 }
+
+export const attributePropMap = {


curious is there an npm module we can extract these from?

I did find one. The only potential problem is that react supports some non-standard attributes, which aren't covered in the package I found, and likely wouldn't be covered by other packages.

how about take it from react itself? You can import HTMLDOMPropertyConfig and SVGDOMPropertyConfig from renderers/dom/shared. I think it's better, because when react team add new property it starts working here without any changes.

This will be going away entirely actually.

ljharb · 2015-12-12T19:22:46Z

docs/api/selector.md

+- attr syntax(`[foo="bar"]`, `[foo]`, etc.);
+
+A note on attribute selectors: For compatibilty, you can use either the
+react prop name, or the native html selector. For example, the following


I still see this as a horribly bad API decision. [] means "HTML attributes", not "React component props" - the two aren't the same thing. Wouldn't the code be a lot simpler to use a different syntax instead of smashing two things into one existing syntax?

In addition, this is a decision that will be almost impossible to unmake - whereas introducing a different syntax now won't in any way prevent bloating the attribute selector syntax later (and just using the same code) if that's what we decide we want.

cc @lelandrichardson

I'm open for changing either way.
@ljharb what about the context of different rendering layers. Think ReactNative, ReactHardware. In those contexts, do we just say the [] isn't for them? I think leland had a good point that the [] selector was built for XML, not explicitly the DOM. so in a ReactNative/Hardware standpoint, the Props are the attributes of the "rendered" xml

as I understand it (@lelandrichardson can confirm) enzyme was originally built to replicate much of jQuery's API, which is why the querySelectorAll syntax is used for the selector string. If we're going to be deviating from it, for React Native or otherwise, that's a bigger discussion - does React Native itself use selector syntax?

@ljharb I can understand your hesitation with the API decision. We solved something similar in the testing library skin-deep with tree.subTreeLike('*', {foo: 'bar'}).

We wanted to query for specific components using props, so we could use specific testing properties like data-testref='foo' that didn't interfere with our ui teams use of classnames.

cc @lelandrichardson @blainekasten

I started on an implementation to use seperate syntax ({} for props, [] for html attr). It seems feasible. In shallow renders, I'm basically faking it by mapping the html attr selector to the matching react prop since I don't get an actual render. I'm just waiting on word from @lelandrichardson if that is the way we want this togo.

I just pushed up the changes that @ljharb requested. Hopefully this can help the conversation move along.

looking for feedback from @lelandrichardson and @ljharb

0xR · 2015-12-16T10:35:53Z

src/MountedTraversal.js

 return inst => instHasId(inst, selector.substr(1));
+ case SELECTOR.ATTR_TYPE:
+ const attrKey = selector.split(/\[([a-z\-\:]*?)(=|\])/)[1];


are we sure attributes can't have capitals?

if not I would expect some useful error message

Good catch. That is actually a bug now that I think about it. svg introduced a lot of camelCase attributes, like preserveAspectRatio

lelandrichardson · 2015-12-16T17:13:02Z

wow, thanks for all this work! I'm going to try and take a closer look tonight after we finish up this hackathon. Looks great!

lelandrichardson · 2015-12-18T01:09:30Z

Hey @blainekasten ,

I hate to give you more work to do... but i was hoping you could change this back to the original [prop] syntax. @ljharb and I discussed the pros/cons of each syntax and we agreed that handling just [prop] and getting rid of {prop} syntax.

To recap, the syntax we would like is:

[prop="foo"] gets nodes with prop="foo"
[foo] gets nodes that have a foo prop defined
there will be no special mapping between props and html attributes such as htmlFor => for.

blainekasten · 2015-12-18T04:23:47Z

No worries. I want to see this land. I can do that. I agree with that API also honestly. Glad to have it sorted out. I'll finish it tomorrow 👍

lelandrichardson · 2015-12-18T17:37:37Z

wow, good work on the tests! Istanbul is becoming a bit of a pain since we are using babel... I need to figure out how to get istanbul working with the original source lines so that it makes more sense. just ignore for now if the percentage goes down.

I'm curious of a couple of things:

What's the behavior of numeric proptypes? Seems like something that we could also use the string selector for (or not?). Either way, the expectations should be tested.

const wrapper = shallow(<div><Foo bar={2} /></div>);
expect(wrapper.find('[bar="2"]')).to.have.length(1);

Does the above pass? (I'm not necessarily saying it should)

lelandrichardson · 2015-12-18T17:39:29Z

src/Utils.js

@@ -116,7 +116,26 @@ export function selectorError(selector) {
 );
 }

-export const isCompoundSelector = /[a-z]\.[a-z]/i;
+export const isCompoundSelector = /([a-z]\.[a-z]|[a-z]\[.*\])/i;


will this always work? what about [foo][bar]?

It does, I tested just tested that exact scenario, but also this test effectively proves it also, https://github.com/airbnb/enzyme/pull/70/files#diff-e08e795cdfa46e03ea97df132b57d75aR167

My testing shows that it doesnt? div[foo][bar] matches but [foo][bar] does not

Maybe test again? I literally just tested both those ideas and they both matched.

lelandrichardson · 2015-12-18T17:42:19Z

Also, what is the expected behavior for falsy but present props?

does <div foo="" /> match [foo]?
does <Foo visible={false} /> match [visible]?

lelandrichardson · 2015-12-18T17:44:32Z

src/ShallowTraversal.js

+ const nodeProps = propsOfNode(node);
+
+ if (propValue) {
+ return nodeProps[propKey] === propValue;


i guess my questions boil down to: should this be == or ===?

That doesn't work for situations like 'false' or 'true'

yah... so we may need some special case logic put in here. let's try and figure out what the corner cases are and what the desired behavior is...

===. A prop of 3 and a prop of '3' are different and shouldn't be selected in the same group.

blainekasten · 2015-12-18T18:00:28Z

Ahh good catch. I didn't think about non-string values.. I'll have to work on this a bit more.

Empty string currently works fine:

<div foo="" /> matches [foo] or [foo=""]
<Foo visible={false} /> DOES match [visible], not sure if that's the right call or not?

I guess in the situation of non string prop values, I would think dropping the quotes would be the way to do it.

So <Foo visible={false} /> could match [visible=false] but not [visible="false"]

lelandrichardson · 2015-12-18T18:56:12Z

@ljharb what do you think? How should empty values be handled? should [foo] match <div foo="" />?

I'm trying to think pragmatically, and it seems to me that if i look for [visible], I do NOT want <Foo visible={false} /> to match...

blainekasten · 2015-12-18T18:59:34Z

If we want to stick to querySelector syntax, a query of [foo] only looks for a node that has that attribute, irrelevant of the value.

Some new code that I have you could do this.

[visible=false] if you want the non-visible things.

ljharb · 2015-12-18T19:00:14Z

That's a very good question - since this is a string-based API, it will already only work for a subset of prop values (and won't work for Symbol props). I think we can just draw a line and say that for this limited form of findWhere/filterWhere, [foo] should not match falsy values, and [foo=${bar}] should mean that a bar of a non-string value should never match anything.

ljharb · 2015-12-18T19:00:55Z

Alternatively, I'd be totally fine with saying that [foo] matches any non-undefined value - and that might be more in line with people's expectations.

lelandrichardson · 2015-12-18T19:08:48Z

I think I like [foo] matching non-undefined-values.

That just leaves the non-string-based values... in this case we could say that things have to be === to each other... (so [foo="2"] would NOT match <Foo foo={2} />).

ljharb · 2015-12-18T19:12:38Z

agreed. I think non-string values is for xWhere to handle.

lelandrichardson · 2015-12-18T19:15:41Z

Let's also add two tests describing its behavior for <Foo ref="foo" /> and <Foo key={1} /> since those are not treated the same as other props in react...

blainekasten · 2015-12-18T19:26:44Z

Feeling a little lost by the string of comments. Can you drop me a few examples of what tests you'd want to pass/fail?

blainekasten · 2015-12-18T19:28:37Z

I don't think adding support for ref makes much sense since React is moving away from the string ref api. It's almost guaranteed that in the coming months/year that react won't support a string for ref and only accept a fn.

lelandrichardson · 2015-12-18T19:29:24Z

Agreed. I don't want to support it... I just want to add a test that asserts that it's not supported so we know that that doesn't change at some point

lelandrichardson · 2016-01-05T17:01:00Z

@blainekasten thanks for bearing with us for this whole conversation!

blainekasten · 2016-01-05T17:01:44Z

No prob! It's a pretty big api addition. Always gotta make sure it serves the right direction.

blainekasten · 2016-01-05T21:28:31Z

@lelandrichardson This is ready to go now! Thanks

lelandrichardson · 2016-01-07T18:57:43Z

@blainekasten one last request: can you squash your commits before I merge?

ljharb · 2016-01-07T19:53:22Z

@blainekasten a rebase would be preferred over a merge

blainekasten · 2016-01-07T19:54:36Z

Yeah. I'm trying to rebase. I always struggle through the squashing process...

ljharb · 2016-01-07T19:56:03Z

sadly github doesn't make it easy with a rebase button. on your branch, git fetch source; git rebase source/master where source is the git remote for this repo should do it tho?

blainekasten · 2016-01-07T19:58:31Z

Yeah.. it is too hard. I am not following exactly for that suggestion.

I tried git rebase -i HEAD~n and squashed the previous commits.. but it didn't squash them haha

ljharb · 2016-01-07T20:01:14Z

Alternatively, you could make a brand new branch locally, recreate it manually by checking things out or cherry picking from the original branch, and then, force push the new local branch to the original remote branch, which will update the PR.

lelandrichardson · 2016-01-07T20:01:20Z

on your branch, figure out the total # of commits n that you have that you want to squash. Run git rebase -i HEAD~n. In the menu, leave the first commit as pick <sha> <message>. For all of the following commits, change it to squash <sha> <message>. Submit that screen (:wq if you're using vim), then in the next screen submit that screen as well, unless you want to change the commit message, which you can do.

After that, run git push -f

blainekasten · 2016-01-07T21:24:11Z

Are you guys happy enough with 2 squashedish commits? haha. I can fix it if you want. I just get so worried when I do this that I'll break something.

blainekasten · 2016-01-07T21:27:21Z

Oh boom. I got this down now. Alright, I think we're good to :)

lelandrichardson · 2016-01-07T22:18:59Z

src/__tests__/Utils-spec.js

+
+ it('returns a boolean if passed a stringified bool', () => {
+ expect(coercePropValue('true')).to.be.true;
+ expect(coercePropValue('false')).to.be.false;


whoops. something got merged into master that prevents these types of tests. You need to change these to .to.equal(true) instead. Our linter prevents it the use of these now. You can run npm run lint to ensure everything is fixed.

when I run the linter, those aren't reported. But I changed them, we'll see if this gets it passing

@blainekasten you may need to fetch and rebase again - there's been some merges today.

blainekasten · 2016-01-09T18:52:45Z

This should be ready to go now. Thanks

lelandrichardson · 2016-01-09T20:01:50Z

hey @blainekasten it looks like it has some merge conflicts. Some stuff got merged in that must be conflicting. Can you rebase once more and resolve whatever conflicts show up? Thanks!

cleanup mounted attr api Add documentation for attr api the rest of the attribute mapping and test for colons react 13/14 compatibility clean up code by utilizing utils method fix lint error Change syntax for react property lookups fix lint errors Fix key lookup bug, and simplify regex Change back to [] syntax for props only fix documentation split out test coverage more test coverage fix lint issue support non-string values for prop querying Add tests for not finding ref or key string based selector only deny undefined values fix lint issues Revert to 80b14d3 support multiple literal types for property lookups WIP: Early push for discussion cleanup Add support for prop selector clean up code by utilizing utils method fix lint error Change syntax for react property lookups Change back to [] syntax for props only split out test coverage fix lint issue support non-string values for prop querying string based selector only fix lint issues Revert to 80b14d3 support multiple literal types for property lookups Revert "support multiple literal types for property lookups" This reverts commit 72872fa. undo revert Trigger new build add support for prop selector fix lint errors

blainekasten · 2016-01-10T01:53:20Z

Alright. Should be good again. Hopefully it can get merged before something else conflicts again :)

Support Property Selector

lelandrichardson · 2016-01-10T06:17:27Z

Awesome work. Thank you!

blainekasten · 2016-01-10T07:40:45Z

Thanks for merging! No problem. I'm excited about this project. Thanks for starting it

blainekasten mentioned this pull request Dec 12, 2015

Add [prop='foo'] CSS syntax #4

Closed

goatslacker reviewed Dec 12, 2015
View reviewed changes

blainekasten changed the title ~~WIP: Attribute Selector~~ Discussion: Attribute Selector Dec 12, 2015

ljharb reviewed Dec 12, 2015
View reviewed changes

blainekasten changed the title ~~Discussion: Attribute Selector~~ Discussion: Attribute/ReactProp Selector Dec 15, 2015

0xR reviewed Dec 16, 2015
View reviewed changes

ljharb mentioned this pull request Dec 18, 2015

How to find an element based on its ref attribute? #82

Closed

blainekasten changed the title ~~Discussion: Attribute/ReactProp Selector~~ Support Attribute Selector Dec 18, 2015

lelandrichardson reviewed Dec 18, 2015
View reviewed changes

lelandrichardson reviewed Jan 7, 2016
View reviewed changes

blainekasten changed the title ~~Support Attribute Selector~~ Support Property Selector Jan 8, 2016

lelandrichardson added a commit that referenced this pull request Jan 10, 2016

Merge pull request #70 from blainekasten/master

53f43ef

Support Property Selector

lelandrichardson merged commit 53f43ef into enzymejs:master Jan 10, 2016

vegetabill mentioned this pull request Mar 25, 2016

find with href attribute of full URL is rejected for being complex #283

Closed

travisperson mentioned this pull request Aug 10, 2016

Selecting React Components via CSS prop selector #534

Closed

This was referenced Oct 1, 2018

Update enzyme-adapter-react-16 in /modules/frontend from 1.1.1 to 1.5.0 project-accelerate/accelerate#263

Open

Update enzyme-adapter-react-16 in / from 1.1.1 to 1.5.0 leonardofaria/leozera-ui#233

Closed

Support Property Selector #70

Support Property Selector #70

Conversation

blainekasten commented Dec 12, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lelandrichardson commented Dec 16, 2015

lelandrichardson commented Dec 18, 2015

blainekasten commented Dec 18, 2015

lelandrichardson commented Dec 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lelandrichardson commented Dec 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blainekasten commented Dec 18, 2015

lelandrichardson commented Dec 18, 2015

blainekasten commented Dec 18, 2015

ljharb commented Dec 18, 2015

ljharb commented Dec 18, 2015

lelandrichardson commented Dec 18, 2015

ljharb commented Dec 18, 2015

lelandrichardson commented Dec 18, 2015

blainekasten commented Dec 18, 2015

blainekasten commented Dec 18, 2015

lelandrichardson commented Dec 18, 2015

lelandrichardson commented Jan 5, 2016

blainekasten commented Jan 5, 2016

blainekasten commented Jan 5, 2016

lelandrichardson commented Jan 7, 2016

ljharb commented Jan 7, 2016

blainekasten commented Jan 7, 2016

ljharb commented Jan 7, 2016

blainekasten commented Jan 7, 2016

ljharb commented Jan 7, 2016

lelandrichardson commented Jan 7, 2016

blainekasten commented Jan 7, 2016

blainekasten commented Jan 7, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blainekasten commented Jan 9, 2016

lelandrichardson commented Jan 9, 2016

blainekasten commented Jan 10, 2016

lelandrichardson commented Jan 10, 2016

blainekasten commented Jan 10, 2016