feature request: elsif

[rsaccon]

of course it can be done with the existing helpers (if, else, unless), but often elsif is just the natural choice people are used too.

[wycats]

I'm not sure how this would be implemented. The else functionality is implemented by passing an inverse option to helpers. I can't think of a way to implement elsif without adding a lot of complexity to the options hash and usage of it.

Thoughts?

[wagenet]

Seeing as there are no suggestions for how to implement this, I'm closing it. If anyone has ideas or a PR for this, we'll gladly reconsider.

[kpdecker]

Reopening as I think the recent inverse and program changes from @mmun might allow for something like multiple chained inverses if we can get the Jison productions to agree.

Some concerns to think about:

1. Is short circuiting an issue with parameter evaluation, particularly subexpressions as arguments?

2. Do we want to enforce the if behavior or is it sensible to allow for any helper? One straw man would be

     {{#if foo}}
     {{#else unless bar}}
     {{#else for bar}}
     {{#else if baz}}
     {{/if}}
   

   With only the opening and closing helper names being checked for matches.

[kpdecker]

In terms of the actual execution, inverse would effectively become a chain, so there would be no helper changes needed and they would not need to be aware of anything more than "there is something after me in the negative case" which they would continue to define as they please.

[wycats]

@kpdecker This is nice! I'm surprised by this, but in a good way.

I'd love to look at an implementation when we have one 😄

[mmun]

I am intrigued as well and curious how it could be generalized for other use cases besides if.

[yiminghe]

a suggestion: you can do elseif parsing in compiler and group them, then test them and run the specified branch in if block.

here is an implementation of xtemplate:
compiler: https://github.com/kissyteam/xtemplate/blob/052de55251cd620ae59f717e7ec8b30924f3b0fa/lib/xtemplate/compiler.js#L280

if: https://github.com/kissyteam/xtemplate/blob/052de55251cd620ae59f717e7ec8b30924f3b0fa/lib/xtemplate/runtime/commands.js#L89

example:

{{#if(x>y)}}
1
{{elseif(x>z)}}
2
{{/if}}

compiled to

var id2 = scope.resolve(["x"]);
    var exp4 = id2;
    var id3 = scope.resolve(["y"]);
    exp4 = (id2) > (id3);
    params1.push(exp4);
    option0.params = params1;
    option0.fn = function (scope, buffer) {
        buffer.append('\n1\n');
        return buffer;
    };
    var elseIfs5 = []
    var elseIf6 = {}
    elseIf6.test = function (scope) {
        var id7 = scope.resolve(["x"]);
        var exp9 = id7;
        var id8 = scope.resolve(["z"]);
        exp9 = (id7) > (id8);
        return (exp9);
    };
    elseIf6.fn = function (scope, buffer) {
        buffer.append('\n2\n');
        return buffer;
    };
    elseIfs5.push(elseIf6);
    option0.elseIfs = elseIfs5;
    pos.line = 1;
    pos.col = 6;
    buffer = ifCommand.call(tpl, scope, option0, buffer);
    return buffer;

[kpdecker]

The basic approach here creates ambiguous parse trees.

{{#foo}}
{{^bar}}
{{/foo}}

and

{{#foo}}
  {{^bar}}
  {{/bar}}
{{/foo}}

Can't be expressed in a context free manner as long as the same syntax construct is used to both start an inversed block and the chained inverse operation.

In order to support this feature, we will need to define a syntax that is only used for the chained operations. One thought is using {{else as the token that will signify chaining. This means that we will have to desupport the {{else foo}}{{/foo}} syntax but this particular syntax feels very weird as a top-level declaration and there is a fix by replacing {{else with {{^ so I think we can get away with such a change.
Current we support {{else foo}}{{/foo}} as a root

[kpdecker]

Closing in favor of #892