Add shortcut for deps from multiple elems

[dfilatov]

If i need deps from multiple elems of block, i should use:

({
    shouldDeps: [
        { block: 'bla', elem: 'e1' },
        { block: 'bla', elem: 'e2' },
        { block: 'bla', elem: 'e3' }
})

It would be more convenient if I could write so:

({
    shouldDeps: { block: 'bla', elem: ['e1', 'e2', 'e3'] }
})

[dfilatov]

cc @veged

[narqo]

@dfilatov

shouldDeps : [
  { block : 'blah', elems : ['e1', 'e2'] }
]

?

BTW: http://ru.bem.info/articles/deps-js-syntax/

[dfilatov]

@narqo, i need deps only from elems, not including the block.

[arikon]

@dfilatov Try

shouldDeps : [
  { elems : ['e1', 'e2'] }
]

[veged]

@arikon that's the same as @narqo suggested -- elems field is short cut for declaration both block and elements, i.e. { block: 'b1', elems: ['e1'] } equal to [{ block: 'b1' }, { block: 'b1', elem: 'e1' }]

but we need possibility to declare elements without block declaration, i.e. { block: 'b1', elem: ['e1', 'e2'] } should be equal to [{ block: 'b1', elem: 'e1' }, { block: 'b1', elem: 'e2' }]

[arikon]

@veged I've got it

[arikon]

@SevInf Have a look at this, please

[SevInf]

Won't it be confusing? This code

shouldDeps: { block: 'blah', elem: ['e1', 'e2'] }

looks almost like this:

shouldDeps : [
  { block : 'blah', elems : ['e1', 'e2'] }
]

and difference between them is not obvious without looking into documentation. May I suggest some alternative, for example:

shouldDeps: [
    {elems:['e1', 'e2'], ofBlock: 'blah'}
]

@arikon, @dfilatov, @veged what do you think?

[veged]

I prefer originally described variant as more consistent with current deps.js format. Yes, it's not obvious at all, but if we need something more "literature" and "verbose" we should architect fully new version of deps.js format.

Also, you always have an option to not use shortcuts and write more verbose and obvious instead of { block: 'blah', elem: ['e1', 'e2'] } — [{ block: 'blah' }, { block: 'blah', elem: 'e1' }, { block: 'blah', elem: 'e2' } ].

On 22.08.2013, at 6:48, Sergej Tatarincev notifications@github.com wrote:

Won't it be confusing? This code

shouldDeps: { block: 'blah', elem: ['e1', 'e2'] } looks almost like this:

shouldDeps : [ { block : 'blah', elems : ['e1', 'e2'] } ] and difference between them is not obvious without looking into documentation. May I suggest some alternative, for example:

shouldDeps: [ {elems:['e1', 'e2'], ofBlock: 'blah'} ] @arikon, @dfilatov, @veged what do you think?

— Reply to this email directly or view it on GitHub.

[SevInf]

IMHO, original proposal will make API more inconsistent - we'll basically have same construction meaning different things depending whether or not its an element of an array. It is also very error-prone. When I have a dependency on e1 and e2 of block1 described like this:

shouldDeps: {
     block: 'block1', elem: ['e1', 'e2'] 
}

if I need to depend on e3 and e4 of block2 I would logically assume I should have an array where previously I had a single item:

shouldDeps: [
     {block: 'block1', elem: ['e1', 'e2']},
     {block: 'block2', elem: ['e3', 'e4']},
}

But instead I'll get a different behavior without any warning. This thread is a great example of confusion we might have: wrong solution was proposed twice and it took 4 comments to figure out the difference from shortcuts we already have.

[veged]

There is no differences in using array or single string, they both mean the same — depend on some elems (without depending on block itself).

On 22.08.2013, at 9:59, Sergej Tatarincev notifications@github.com wrote:

IMHO, original proposal will make API more inconsistent - we'll basically have same construction meaning different things depending whether or not its an element of an array. It is also very error-prone. When I have a dependency on e1 and e2 of block1 described like this:

shouldDeps: { block: 'block1', elem: ['e1', 'e2'] } if I need to depend on e3 and e4 of block2 I would logically assume I should have an array where previously I had a single item:

shouldDeps: [ {block: 'block1', elem: ['e1', 'e2']}, {block: 'block2', elem: ['e3', 'e4']}, } But instead I'll get a different behavior without any warning. This thread is a great example of confusion we might have: wrong solution was proposed twice and it took 4 comments to figure out the difference from shortcuts we already have.

— Reply to this email directly or view it on GitHub.

[dfilatov]

это нужно портировать в соответствующую v2-технологию

[arikon]

@SevInf Готово к портированию

[floatdrop]

Please move this logic to external module and standartize it. I find some places very confusing (including this one).

[floatdrop]

Also this should could be done like that:

shouldDeps : ['e1', 'e2'].map(function (e) { return {block: 'b1', elem: e}; });

And definatly not be included in deps standard.

[veged]

@floatdrop doesn't agree with .map() variant — such verbose stuff :-/

[qfox]

@veged There is another variant with arrows.

['e1', 'e2'].map((e) => {block: 'b1': elem: e})

But elem and elems names confusing when one of them canceling block dep itself. That's strange idea to rename elem to elems ;-\

Can I suggest that you want to cancel including block itself by default and deprecate elem property? In other way that's very confusing thing.

[veged]

@zxqfox I'm not gonna discuss about arrows ;-) sorry ;-)

speakings about confusing — there is some because of just small letter s (not a lot for difference and many inattentive people often do not notice it) but in general logic it's pretty simple to understand and remember:

• { block: 'b1', elems: ['e1', 'e2'] } — you declare block with child elementS (many declarations in one object)
• { block: 'b1', elem: 'e1' } — you declare element of block
• after that just add shortcuts for single elem array ('e1' ~ ['e1']) and for array (vies versa)

[qfox]

Yes, but actually that's not clear:

{ block: 'b1', elems: ['e1', 'e2'] } — you declare block with child elementS (many declarations in one object)

I'm not sure but probably if just freeze naming pattern for internal uses (if we need it) we can use just these:

• 'b1' - block
• 'b1__e1' element of block
• 'b1_m_v' - mod of block (still without block)
• 'b1__e1_m_v' - mod of element (without block/element)
• { block: 'b1', elem: 'e1' } // context without dependencies, should throw error
• { block: 'b1', elem: 'e1', deps: ['__e1', '__e2'] } // context with 2 elements

That's a quietly another format but feels like we are in the deadlock. Need to think different.

Maybe just implement context property. Something like that:

• { block: 'b1', elems: ['e1', 'e2'] } should include block with elements
• { ctx: { block: 'b1' }, elems: ['e1', 'e2'] } should include only elements

So the legend will be simple: includes all described in the root.

[qfox]

@floatdrop @veged Is this abandoned?

[floatdrop]

@zxqfox maybe.