-
Notifications
You must be signed in to change notification settings - Fork 95
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
i-bem__dom: update _elemCache on findElem #842
Conversation
return _self.buildClass(name, modName, modVal); | ||
}).join(',.'), | ||
res = findDomElem(ctx, selector); | ||
|
||
(ctx === this.domElem) && names.forEach(function(name) { | ||
var key = _self.buildClass(name, modName, modVal), | ||
elem = this._elemCache[key] = res.filter('.' + key); |
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.
In most cases we find a single elem (names.length === 1
). So we can avoid unnecessary res.filter
:
var isSingleName = names.length === 1;
...
elem = this._elemCache[key] = isSingleName? res : res.filter('.' + key);
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.
Sounds reasonable, thanks!
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.
Is there difference between name + buildModPostfix(modName, modVal)
and _self.buildClass(name, modName, modVal)
?
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.
definitely — name + buildModPostfix(modName, modVal)
more like violation of encapsulation of building full class
/cc @dfilatov can you review it? |
What's with coverage? |
(just in case...): you can investigate the coverage decreasing directly on Coveralls |
I didn't see anything about |
Oh, sh.., looks like we have a fail positive here. Take a look at the build logs in Travis: there are few failed specs. /cc @tadatuta @andrewblond We got a critical problem with enb-bem-specs here! |
Fixed bug. Need review ;-) |
names.split(' ').map(function(name) { | ||
return _self.buildClass(name, modName, modVal); | ||
}).join(',.'), | ||
keys = names.map(function (name) { |
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.
code style problem here
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.
Sorry, fixed. How it doesn't caught on pre-commit?..
res = findDomElem(ctx, selector); | ||
|
||
// caching results if possible | ||
(ctx === this.domElem) && keys.forEach(function(key, i) { |
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.
As far as I remember, it's not save to compare jQuery-nodes in this way. Check this:
var link = $('.link:eq(0)');
link === $(link); // ☚ false
Can you compare underlying DOM-nodes instead?
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.
You're right. Need to fix that.
@zxqfox I'm still puzzled how |
@dfilatov Idea was to remove |
I open i-bem__dom.js with your changes and try to find substring "prevObject". |
Oh, my god. Let's not to use jquery internals. |
Okay, but |
Why? |
Because |
If I lose link to |
That's why I tried to delete it. in other way it will be stored in |
i-bem__dom: update _elemCache on findElem
Partially fixes #347 Ref bem/bem-core#842 Closes gh-634
Fixes #583