-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Use postcss-selector-parser for selector handling #458
Conversation
Very nice, I was just mentioning doing something like this here. Do you know if this would also resolve #456? @ljharb what do you think? |
return list; | ||
}, []); | ||
} | ||
|
||
handleSelectors(selectors, wrapper) { | ||
const recurseSelector = (offset, fn, pre) => { | ||
const predicate = pre || this.buildPredicate(selectors[offset]); | ||
const predicate = pre || this.buildPredicate(selectors[offset].toString()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
toString
is not guaranteed to return a String - please wrap in String()
instead, throughout.
Made a few comments - overall I think this looks awesome! @jacobp100, could you add more shallow and mount tests that cover a number of expected-to-work selectors, so that things don't break without us knowing in the future? |
@jacobp100 I mentioned a couple of valid selectors that are broken in this comment. If we could test those as well that'd be great. |
const nodes = getAst(selector).nodes[0]; | ||
return AND(nodes.map(node => { | ||
switch (node.type) { | ||
case 'class': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit nit, but the old way of using object constants seemed safer/nicer than just strings. Can you update this to use constants?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The strings come from postcss-selector-parser
, and aren't exported. But I could definitely put a map in util if you think that's best!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. Just put it in a map so there is a central place of seeing the node types supported
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would also be great to file an issue or send a PR upstream to get postcss-selector-parser
to export the strings.
This is awesome and exciting. Thanks for doing this work @jacobp100 |
This LGTM! @lelandrichardson, any final thoughts before we merge? |
For reference, I've opened a PR upstream to export the selector types: postcss/postcss-selector-parser#70 |
Really liking this direction.... Thanks for this work @jacobp100 . I have a couple of questions though:
Sorry if I'm missing something... but I feel like this needs to be merged in with a little bit more care. I love the direction and it seems like this will be much more robust than attempting the parsing ourselves, but let's make sure we understand the change we are making, and ensure that any functionality that we are adding ends up working as close to the CSS spec as it can be, or if it differs, documenting the differences. Does that seem reasonable? |
Agreed. I think it would make sense to throw for multiple selectors. I think I throw for all invalid selectors. Can you see a case where I haven't? I'm actually looking into traversals in another branch. It's a bigger undertaking though. |
One concern I have is bringing in a dependency that isn't being actively maintained. Looking at If we make this a dependency and run into upstream issues we may be facing an uphill battle getting those fixed. They could just be busy right now, but it's worth considering. edit: coming back to this a few months later, this was dumb 👎 few commits !== unmaintained. |
If it's abandoned that's one thing, but we can always fork it and publish our own in that case - I'm not too concerned about anything that's in a git repo. |
An alternative that's been brought up before is this: https://github.com/jquense/bill which is used in https://github.com/jquense/teaspoon cc @jquense to see if he has anything to add on this thread! |
I've suggested bill before as a possibility. i'd be happy to have it consumed by more testing libraries, I'd also be happy to have more collaborators which may be a better option to forking something :). bill solid at this point and supports back to react13 |
@jquense coming back to this, it looks like |
@aweary ya feel free to ping me where ever if you have any questions/concerns 👍 |
@jacobp100 is there any chance you still want to work on this? |
I think this pr should be complete. But let me know if you have any bugs! |
@jacobp100 at the least it'd need a fresh rebase - do you mind doing that? |
@jacobp100 would you mind rebasing and resolving the merge conflicts? If not, no worries. I can try to take this over if you don't have the time. I'd really like to get this merged soon. |
@aweary you are everywhere man |
@jquense so many interesting projects, so little time 😄 |
@aweary I know! any shot of y'all incorporating https://github.com/jquense/bill ? id love to not maintain my other testing library on top of it and just use enzyme :P |
@jacobp100 At this point Enzyme has been entirely rewritten and this PR has fallen really far out of sync. I'm going to close this in favor of #1086 which uses a custom selector parser that supports the variant selector grammar we expect and utilizes the new RST spec we've defined. Sorry this never got merged, we really appreciate all the hard work you did on this! |
No description provided.