i-bem__dom: add shortcut for this.elem(elemName, boolModName, true) as this.elem(elemName, boolModName)

[dfilatov]

No description provided.

[qfox]

That's strange because better to find all elems with name elemName and which has mod boolModName with any value by this.elem(elemName, boolModName).

[dfilatov]

@zxqfox I disagree with you. We've already have the same behaviour for setMod(elem, boolModName). Moreover, I can't even contemplate any reasonable case to find all the elems with any mod value, but I have enough cases to find elem with boolean mod.

[qfox]

@dfilatov Wait, but if you looking for boolean mod then you won't check it's value, right?

[dfilatov]

@zxqfox I'll check that value === true.

[qfox]

@dfilatov I just want to understand what's the difference. I don't see a big difference between checking for true, and just existing. But still if you want to say that elem(name, mod, [val=true]) is more intuitive than elem(name, mod, [val=undefined]) — I'm not sure that you're right. Even if you have a lot of cases to find your elems with boolean mods. Right?

[qfox]

Btw, checking for mod existence will totally cover searching of boolean mods but still will be useful for non-boolean mods. Reverse is not true.

[dfilatov]

@zxqfox
Is it clear for you that setMod(modName) is a shortcut for setMod(modName, true), not for setMod(modName, undefined)?
There's a difference between checking for true and just existing when you're finding elem by css selector.
.block__elem_modName is a simplest selector, which is heavily optimized in the browsers. There's no so simple selector for your case.

[qfox]

@dfilatov Actually, nope. But if you insist — I'll try to apply it for myself as clear. It will be hard but I'll try.

About searching by css selectors: Am I right that we loading all dom elements with i-bem class so we have links to them all in memory? Am I right that we know which ones has modifiers? If so should we depend on css selectors? How we can find non-dom blocks with modifiers? That's smells like inconsistent hell for me. ;-(

[qfox]

Stupid idea. We can add both classes for modifiers if you insist on using css selectors: .some_mod and .some_mod_value, but use the one with value for js.

[dfilatov]

@zxqfox Don't get me wrong, I don't insist, but It's a current behaviour for setMod. Boolean mods are much more widely used that mods with multiple values.
About css selectors and i-bem class:

• i-bem class presents only for blocks with js (in v3 for elems with js as well)
• if we even had all blocks and elems in memory (but actually we didn't), we wouldn't have "ancestors <-> descendants" relationships. We have only DOM for such relations.

[qfox]

@dfilatov Still that's not clear to get only items with boolean mods by .elem('elem', 'mod') ;-( But I got the reason why we can't do it.

[qfox]

I think undefined could be treated as something. And boolean mods then will be mods with something implicit. If we going to add these mods we can rethink boolean mods without changing format of lovely short classes. And in this way I strongly agree with these shortcuts.

Just thoughts.