Else always uses cache in condition

[fracz]

The cache disabling feature we have introduced recently works well in if, but it is broken when it comes to the else.

In the first commit (prior to the boolean argument refactoring) the else directive used the cache from the linked if.

However, now the else is always caching the view just like before the feature.

I feel responsible for this missing behaviour, but the main question is whether we want the else to follow the if and always be cached or not cached, i.e.:

<div if="condition.bind: cond; cache: false"></div>
<div else></div>

or would you prefer to declare it explicite, i.e.:

<div if="condition.bind: cond; cache: false"></div>
<div else="cache: false"></div>

@bigopon @EisenbergEffect

[EisenbergEffect]

I'm thinking that else should use the if cache strategy by default but that you should be able to supply one for else if you need it to be different. I'd like to hear what @bigopon things.

[bigopon]

I think else should by default follow if, but I imagine there could be scenario where else may want to cache while if may not. It's 4 possible combinations here.

I think this is where we may want a new API like processTemplate for template controller, to have the ability to write:

<div if.bind="cond" no-cache></div>
<div else no-cache></div>

and no-cache will be stored in BehaviorInstruction instance for later passing down to If/Else instances

or we could also pick up existing mechanism of view-cache:

<div if.bind="cond" view-cache="0"></div>
<div else view-cache="0"></div>

cc @fkleuver @jods4

[fkleuver]

I was thinking about something like this for vNext earlier because there currently is no way to tell a repeater how to cache without manually building the instructions.

I think a view-cache (or simply cache - there is no native html attribute with that name anyway) attribute is a good way to solve that problem. Every template controller could have it, else shouldn't be an exception imo. The template compiler can easily be modified in both vCurrent and vNext to look for that attribute and add the information to the lifting instruction.

[EisenbergEffect]

It should be there in vCurrent but the implementor of the template controller has to take advantage of it in certain ways explicitly. So, maybe we can just make it better in vNext.