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

i-bem__dom: update _elemCache on findElem #842

Merged
merged 1 commit into from
Apr 16, 2015
Merged

i-bem__dom: update _elemCache on findElem #842

merged 1 commit into from
Apr 16, 2015

Conversation

qfox
Copy link
Member

@qfox qfox commented Jan 30, 2015

Fixes #583

@coveralls
Copy link

Coverage Status

Coverage increased (+0.38%) to 83.59% when pulling e94653c on issues/583@v2 into 992df34 on v2.

@coveralls
Copy link

Coverage Status

Coverage decreased (-3.09%) to 80.13% when pulling 51dc32f on issues/583@v2 into 992df34 on v2.

@coveralls
Copy link

Coverage Status

Coverage decreased (-3.09%) to 80.13% when pulling 24295bf on issues/583@v2 into 992df34 on v2.

@qfox qfox added the v2 label Jan 30, 2015
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);
Copy link
Member

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);

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds reasonable, thanks!

Copy link
Member Author

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) ?

Copy link
Member

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

@veged veged added this to the 2.6 milestone Jan 30, 2015
@coveralls
Copy link

Coverage Status

Coverage decreased (-3.09%) to 80.13% when pulling 0369057 on issues/583@v2 into 992df34 on v2.

@narqo
Copy link
Member

narqo commented Mar 5, 2015

/cc @dfilatov can you review it?

@qfox
Copy link
Member Author

qfox commented Mar 5, 2015

What's with coverage?

@narqo
Copy link
Member

narqo commented Mar 5, 2015

(just in case...): you can investigate the coverage decreasing directly on Coveralls

@qfox
Copy link
Member Author

qfox commented Mar 5, 2015

I didn't see anything about common.blocks/i-bem/__dom/i-bem__dom.js but see common.blocks/i-bem/i-bem.vanilla.js change.

@narqo
Copy link
Member

narqo commented Mar 6, 2015

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!

@coveralls
Copy link

Coverage Status

Coverage increased (+0.28%) to 83.92% when pulling 46c2ec8 on issues/583@v2 into 9876bf9 on v2.

@qfox
Copy link
Member Author

qfox commented Mar 11, 2015

Fixed bug.
Made a little refactoring.
Squashed commits.

Need review ;-)

enb/enb-bem-specs#21

names.split(' ').map(function(name) {
return _self.buildClass(name, modName, modVal);
}).join(',.'),
keys = names.map(function (name) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code style problem here

Copy link
Member Author

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?..

@coveralls
Copy link

Coverage Status

Coverage increased (+0.28%) to 83.92% when pulling 0b4b89d on issues/583@v2 into 9876bf9 on v2.

@blond
Copy link
Member

blond commented Mar 11, 2015

Oh, sh.., looks like we have a fail positive here. Take a look at the build logs in Travis: there are few failed specs.

@zxqfox, @narqo #908

res = findDomElem(ctx, selector);

// caching results if possible
(ctx === this.domElem) && keys.forEach(function(key, i) {
Copy link
Member

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?

Copy link
Member Author

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.

@coveralls
Copy link

Coverage Status

Coverage decreased (-15.49%) to 68.16% when pulling 2436afc on issues/583@v2 into 9876bf9 on v2.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.54%) to 83.87% when pulling 0a49cc7 on issues/583@v2 into 2fe510b on v2.

@dfilatov
Copy link
Member

@zxqfox I'm still puzzled how prevObject is used.

@qfox
Copy link
Member Author

qfox commented Mar 12, 2015

@dfilatov Idea was to remove res (placed in prevObject key) to reduce links count and make possible to collect garbage. I can drop it if you don't like it.

@dfilatov
Copy link
Member

I open i-bem__dom.js with your changes and try to find substring "prevObject".
There's only occurrence:
delete elem.prevObject;

@qfox
Copy link
Member Author

qfox commented Mar 12, 2015

@dfilatov
Copy link
Member

Oh, my god. Let's not to use jquery internals.

@qfox
Copy link
Member Author

qfox commented Mar 12, 2015

Okay, but res will never be collected ;-)

@dfilatov
Copy link
Member

Why?

@qfox
Copy link
Member Author

qfox commented Mar 12, 2015

Because res.filter create new object for each name/key and res is stored in prevObject property in each new object. Nvm.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.53%) to 83.86% when pulling afd06ab on issues/583@v2 into 2fe510b on v2.

@dfilatov
Copy link
Member

If I lose link to res, they will be collected, won't they?

@qfox
Copy link
Member Author

qfox commented Mar 12, 2015

That's why I tried to delete it. in other way it will be stored in prevObject property. Where I'm wrong? I can't get ;-)
As an opposite there is another idea to make empty chain ($()) and push there filtered elements. But is it worth?

@narqo narqo removed this from the 2.6 milestone Mar 13, 2015
narqo pushed a commit that referenced this pull request Apr 16, 2015
i-bem__dom: update _elemCache on findElem
@narqo narqo merged commit 2ce9b34 into v2 Apr 16, 2015
@narqo narqo deleted the issues/583@v2 branch April 16, 2015 14:13
qfox pushed a commit that referenced this pull request May 14, 2015
qfox pushed a commit to bem/bem-bl that referenced this pull request Jun 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants