-
-
Notifications
You must be signed in to change notification settings - Fork 5
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
expose calculateSelectorNode
#23
base: main
Are you sure you want to change the base?
Conversation
Apologies for the delay but only now I took a good look into this PR. One thing I’m wondering is why |
~~The existing function already returned a single object, so I simply renamed it and exported it. It does make sense to me however to keep this method as small as possible, because it's easy to integrate and mock for testing.~~ edit: interpreted your question incorrectly For my use case I generate sometimes over 10,000 Specificity instances, each with a small enough footprint. Separating instantiating the |
My css-analyzer package has benchmarks enabled in CI and running it with the changes from this MR makes the analyzer 25-50% faster! projectwallace/css-analyzer#423 (comment) (I don't necessarily trust the benchmarks blindly and ~50% is probably waaaay too much, but I'm very confident that it's faster because it's making a lot fewer function calls and memory allocations) |
closes #17
calculateSelectorNode
next to the existingcalculate
functionSpecificity.calculateSelectorNode(selector: string)
+ testscalculateSelectorNode
does not need to referenceSpecificity
each time/test/standalone
is implemented correcty. I suspect the existing tests forcalculate
don't actually test it's implementation so I did mine a little different than the existing tests. Please double-check my work 😅. Also opened Question: are standalone tests correct? #24 for further discussion.