-
Notifications
You must be signed in to change notification settings - Fork 48
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
Improved mix behaviour #197
Conversation
@@ -213,7 +213,8 @@ BEMHTML.prototype.renderMix = function renderMix(entity, | |||
if (typeof item === 'string') | |||
item = { block: item, elem: undefined }; | |||
|
|||
var hasItem = item.block || item.elem; | |||
var hasItem = (item.block || item.elem) && | |||
!(item.mods && item.block === entity.block); |
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.
Pretty scared about this condition. Can we add more tests for edge cases?
Like:
{ block: 'b', elem: 'e', mix: { elem: 'e' } } // 1
{ block: 'b', elem: 'e', mix: { block: 'b', elem: 'e' } } // 2
{ block: 'b', content: { elem: 'e', mix: { elem: 'e' } } } // 3
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.
@zxqfox it’s defferent cases:
- elem with mixed the same elem
- elem with mixed elem with elemMods
- block with mixed the same block
- block with mixed block with mods
Now 1, 2, 3 will render as duplicates but who cares? No degradation with current version, don’t afraid.
This PR about number 4 only. The reason is “I want to mix block (for CSS purposes) with mods without apply templates”.
//cc @tadatuta
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.
Rewrite condition then.
item.elem || item.block && !(item.mods && item.block === entity.block)
517787f
to
921b07a
Compare
👍 |
I remember this issue and return to PR at monday. |
🆙 This issue is much more interesting than it seems at first sight. See updated PR description. |
I tried to run bench. prev — 5.0.0. miri$ node ./run.js --compare
render:basic:next x 553,115 ops/sec ±0.58% (88 runs sampled)
render:basic:prev x 541,073 ops/sec ±0.92% (87 runs sampled)
render:islands:next x 917 ops/sec ±0.94% (87 runs sampled)
render:islands:prev x 972 ops/sec ±1.38% (86 runs sampled)
render:showcase:next x 1,766 ops/sec ±1.41% (84 runs sampled)
render:showcase:prev x 1,890 ops/sec ±1.38% (86 runs sampled) JFYI. |
try benches few times. for me it often results in different timing each time I try. |
@tadatuta yes, of course I tried to run it several times. I saw no degradation. |
|
||
if (item.elem) { | ||
if (item.elem !== entity.elem && item.elem !== context.elem) { | ||
hasItem = true; |
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.
at least hasItem = item.elem !== entity.elem && item.elem !== context.elem
c3b9f4e
to
0efadf3
Compare
miri$ node ./run.js --compare --min-samples 1000
render:basic:next x 576,966 ops/sec ±0.98% (1038 runs sampled)
render:basic:prev x 578,712 ops/sec ±0.37% (1037 runs sampled)
render:islands:next x 990 ops/sec ±0.15% (1037 runs sampled)
render:islands:prev x 1,015 ops/sec ±0.20% (1037 runs sampled)
render:showcase:next x 1,939 ops/sec ±0.18% (1036 runs sampled)
render:showcase:prev x 1,908 ops/sec ±0.23% (1037 runs sampled) |
Nice! Thanks for fixing all these stuff. LGTM |
May I merge? |
LGTM |
@veged thank you for your attention! 🎱 |
Related: bem/bem-core#805
+15 test cases
–1 bug
Fixed (degradation)
1. bemhtml should duplicate block class if mix several block with mods to elem in the same block.
Because block class must have for mix block with mods to block elem.
Example:
4.3.4 result:
demo
5.0.0 result:
demo;
This PR result:
Improved
2. bemhtml should not duplicate block class if mix is the same block with mods.
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
3. bemhtml should not duplicate elem class if mix is the same elem.
Weird case, but for completeness why not to check it
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
4. bemhtml should not duplicate elem class if mix is the same block elem.
Weird case, but for completeness why not to check it.
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
5. bemhtml should not duplicate elem class if mix the same elem to elem in block.
Weird case, but for completeness why not to check it.
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
6. bemhtml should not duplicate elem class if mix is the same block elem with elemMods.
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
7. bemhtml should not duplicate block elem elemMods class
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
“Who cares” cases (zero cost but enjoyable)
Weird cases, but for completeness why not to check it.
8. bemhtml should duplicate block mods class if mix is the same block with mods.
But who cares? It’s pretty rare case.
To fix this we need to compare each key/value pairs. It’s too expensive.
I believe that developers should not want to do this.
4.3.4 result:
demo
5.0.0 result:
demo
This PR result:
9. bemhtml should duplicate elem elemMod class
But who cares? It’s pretty rare case.
To fix this we need to compare each key/value pairs. It’s too expensive.
I believe that developers should not want to do this.
4.3.4 result:
demo
5.0.0 result:
demo
This PR result: