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

Fast and consistent matchNode #39

Open
Inviz opened this issue Apr 19, 2011 · 6 comments
Open

Fast and consistent matchNode #39

Inviz opened this issue Apr 19, 2011 · 6 comments

Comments

@Inviz
Copy link

Inviz commented Apr 19, 2011

Hello there.

Slick.match() may return following values:

  • false - nothing is matched
  • true - selector equals node or native matcher used (?)
  • node - when the node was matched

Thing is that a returned node may be useful, but I does not return it all the time reliably.

My suggestion is to return either false or true all the time and allow to pass node as a third argument.

This is my latest take on the problem:

https://gist.github.com/927160

First of all, it doesnt use global search to do the matching of a complex selector.
Second, it figures out if the last reversed bit will return single or many elements (e.g. "~ div" and "+ div" will return array or a node respectively when reversed)
Third, it has a third argument that does the required check (e.g. you can do Slick.match(li, '> li', ul)). Basically it reverts the selector and checks if the needle is in the haystack.
Fourth, it consistently returns true or false if it's matched or not. Not the node.

It's fast and works with all selectors in my app (i use much of the complex stuff). Sorry for no tests.

@Inviz
Copy link
Author

Inviz commented Apr 20, 2011

@markiz @subtleGradient @cpojer @fabiomcosta @arian

I'd be happy for some feedback This ultimate reverse-matcher is both faster and more powerful than what we have now.

@cpojer
Copy link
Member

cpojer commented Apr 20, 2011

What about an actual pull request so we can run the specs with your changes?

@fabiomcosta
Copy link
Member

yeah, make a pull request and let us use the specs we have today, to make
sure everything is ok.
The idea is awesome, if everything passes it will be pulled for sure :)
Thanks!

Fbio Miranda Costa
twitter: @fabioMiranda
github: fabiomcosta

On Wed, Apr 20, 2011 at 6:58 AM, cpojer <
reply@reply.github.com>wrote:

What about an actual pull request so we can run the specs with your
changes?

Reply to this email directly or view it on GitHub:
#39 (comment)

@Inviz
Copy link
Author

Inviz commented Apr 21, 2011

#40

Pull request is there. Benchmarks revealed that the fastest way was the oldest one when nativeMatchSelector was available. Recursive (mine) is a little bit slower but it wins big time when there's no cheating nativeMatchSelector given.

@Inviz
Copy link
Author

Inviz commented Apr 21, 2011

I couldnt figure out how to run the full test suite, it didnt work for me.

@arian
Copy link
Member

arian commented Apr 21, 2011

git submodule update --init --recursive

Browse to /SlickSpec/Runner/

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

No branches or pull requests

4 participants