The Mod Field about bem-sdk

[apsavin]

I did not get 2.
{ block: 'button', mod: { name: 'size', val: false } }
vs
{ block: 'button', modName: 'size', modVal: false }
Why less confusion?

[blond]

@apsavin I think that now { block: 'button', modName: 'size', modVal: false } will consider equivalent { block: 'button', modName: 'size' }.

If for boolean modifiers will the short form { block: 'button', mod: 'disabled' } then no one will want to write { block: 'button', mod: { name: 'disabled', value: true } or { block: 'button', mod: { name: 'disabled', value: false } and the full form will always be used for key-value modifiers.

[vithar]

👍

[tadatuta]

@blond isn't it just yet one more format for absolutely same purpose?

are there real places one must write such form manually (except for i-bem which you won't change anyways)?

[blond]

@tadatuta i-bem works with BEM entities, but bem-naming works with BEM entity parts. It's means that the syntax does not necessarily coincide.

For example, i-bem can use mods: { key: 'value' }.

In addition the i-bem and bem-naming have different users. It's means that the consistency of the formats is not important in this case.

In my opinion the mod field is better than modName + modVal fields. So I still want to make mod field.

[blond]

@tadatuta also i-bem can support mod field with old modName + modVal option

[tadatuta]

also i-bem can support mod field with old modName + modVal option

?

[blond]

bem-entity-name use mod field and support modName and modVal for backward compatibility.

I think bem-naming must do the same.

[blond]

Fixed in #148