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

Use postcss-selector-parser for selector handling #458

Closed
wants to merge 3 commits into from
Closed

Use postcss-selector-parser for selector handling #458

wants to merge 3 commits into from

Conversation

jacobp100
Copy link

No description provided.

@aweary
Copy link
Collaborator

aweary commented Jun 16, 2016

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());
Copy link
Member

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.

@ljharb
Copy link
Member

ljharb commented Jun 16, 2016

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?

@aweary
Copy link
Collaborator

aweary commented Jun 16, 2016

@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':
Copy link
Contributor

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?

Copy link
Author

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!

Copy link
Contributor

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

Copy link
Member

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.

@blainekasten
Copy link
Contributor

This is awesome and exciting. Thanks for doing this work @jacobp100

@ljharb
Copy link
Member

ljharb commented Jun 16, 2016

This LGTM! @lelandrichardson, any final thoughts before we merge?

@aweary
Copy link
Collaborator

aweary commented Jun 16, 2016

For reference, I've opened a PR upstream to export the selector types: postcss/postcss-selector-parser#70

@lelandrichardson
Copy link
Collaborator

Really liking this direction.... Thanks for this work @jacobp100 . I have a couple of questions though:

  1. I gather we are ignoring combined selectors (ie, .foo, .bar) in some situations (or is it all situations?). In this case, we should probably throw a warning or something to the developer explaining that only the first one is being used, or else it might be misleading.
  2. are we no longer warning at all for unsupported CSS selectors? It seems there are still a number left.
  3. this gets an AST for the CSS selectors (which is great!) but leaves traversal up to us. For descendant selectors etc. this can be quite hairy. I don't seem to see a lot of tests covering this behavior? It seems important to me if we are adding descendant (and other nonlocal selectors like sibling, direct descendant, etc.) then we will really want to make sure we get this right.

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?

@jacobp100
Copy link
Author

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.

@aweary
Copy link
Collaborator

aweary commented Jun 16, 2016

One concern I have is bringing in a dependency that isn't being actively maintained. Looking at postcss-selector-parser it doesn't seem like they are actively maintaining it at the moment. The last commit was almost a month ago and there are PRs that haven't been addressed for about the same amount of time.

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.

@ljharb
Copy link
Member

ljharb commented Jun 16, 2016

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.

@lelandrichardson
Copy link
Collaborator

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!

@jquense
Copy link
Contributor

jquense commented Jun 16, 2016

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

@aweary
Copy link
Collaborator

aweary commented Oct 18, 2016

@jquense coming back to this, it looks like bill would take care of traversal for us right? I would be open to trying to implement this with bill instead so we don't have to include a bunch of AST traversal logic here too.

@jquense
Copy link
Contributor

jquense commented Oct 18, 2016

@aweary ya bill, exposes a bunch of traversal utilities, and abstracts out the differences between element and instance trees so that you can use the same traversal logic (where that makes sense) for both. High level it wraps matched trees in Node objects that expose DOM Element-esque traversal properties prevSibling, children, parentNode, etc; it makes implementing a wide range of selectors nice and easy

feel free to ping me where ever if you have any questions/concerns 👍

@aweary
Copy link
Collaborator

aweary commented Feb 15, 2017

@jacobp100 is there any chance you still want to work on this?

@jacobp100
Copy link
Author

I think this pr should be complete. But let me know if you have any bugs!

@ljharb
Copy link
Member

ljharb commented Feb 16, 2017

@jacobp100 at the least it'd need a fresh rebase - do you mind doing that?

@aweary
Copy link
Collaborator

aweary commented Apr 9, 2017

@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 aweary self-assigned this Apr 9, 2017
@jquense
Copy link
Contributor

jquense commented Apr 9, 2017

@aweary you are everywhere man

@aweary
Copy link
Collaborator

aweary commented Apr 9, 2017

@jquense so many interesting projects, so little time 😄

@jquense
Copy link
Contributor

jquense commented Apr 10, 2017

@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

@aweary
Copy link
Collaborator

aweary commented Aug 31, 2017

@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!

@aweary aweary closed this Aug 31, 2017
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.

6 participants