Enable else on the template after using if:true | false

[AllanOricil]

Is your feature request related to a problem? Please describe.

At the moment, to conditionally show something in the template, developers have to write something like this:

<template>
    <div>
        <template if:true={showA}>A</template>
        <template if:false={showA}>B</template>
    </div>
</template>

and because getters are not memoized (#243) lwc calls showA twice, which is a problem that has already been adressed and has a proposed fix (#2300).

But, considering that the memoization problem is fixed, you could also improve performance and DX by enabling developers to do write this:

<template>
    <div>
        <template if:true={showA}>A</template>
        <template else>B</template>
    </div>
</template>

I think performance would be increased because the template engine wouldn't even evaluate the "else" when "if:true" is resolved to true. In the current way, I think even with memoization the engine would still waste time evaluating the "if:false" condition, right?

As for DX, it is much easier to read the example above. Vue does that and everyone loves it.

Describe the solution you'd like
Change this

<template>
    <div>
        <template if:true={showA}>A</template>
        <template if:false={showA}>B</template>
    </div>
</template>

to this

<template>
    <div>
        <template if:true={showA}>A</template>
        <template else>B</template>
    </div>
</template>

Describe alternatives you've considered
Currently developers have to do this

<template>
    <div>
        <template if:true={showA}>A</template>
        <template if:false={showA}>B</template>
    </div>
</template>

Additional context
N/A

[caridy]

I don't remember all the details about the then/else situation. Maybe @diervo remembers. Few things that come to mind:

1. the compiler doesn't have relationships between nodes beyond parent/child relationship (cc @pmdartus to keep me honest here).
2. original implementation was then/else but we dropped (in the early days).
3. it is an observable difference between access the getter twice vs once, if a getter is used, which is one of the problems that we are trying to solve cc @jodarove
4. there was something about the flattening process (internal mechanism in the compiled code) with respect to the else clause. So this might very well be just a technical challenge.

[AllanOricil]

@caridy @diervo you guys can do it!

[nolanlawson]

Related: #2985 #2988

[AllanOricil]

@nolanlawson is this implemented by this release?

https://developer.salesforce.com/blogs/2023/01/lwc-enhancements-for-developers-learn-moar-spring-23

[AllanOricil]

Other questions:

Why prepending conditionals with the word "lwc:"?
Adding a new way of doing the same thing just decreases DX. People will have to learn things again, and eventually you will have to deprecate the old way.
I also don't understand why an LWC template engine has to prepend every parameter with "lwc". Vue, for instance, enabled developers to use short versions of 'vue' directives. For instance, 'v-on:click' can just become "@click". Vue maintainers probably understood it improves DX when you write less, and that it was redudant to keep using "v-<*>" on a Vue template engine.
What was the problem for not enhancing the current template engine to enable this? Can't it be fixed or would it take a long time to be fixed? If it could be fixed, it would be better to wait until you can do it while maintaining the current way.

[nolanlawson]

@AllanOricil Yep, as the blog post mentions, this is shipping in Spring '23.

Why prepending conditionals with the word "lwc:"?

This was discussed in the RFC. After weighing the pros and cons, we decided to create a brand-new set of directives for this. BTW we welcome comments from the community on our RFCs; you can follow that repo to keep up-to-date on what we're planning. 🙂

I agree that deprecating the existing if:true/if:false will be no fun, but we do have a set of codemods, and once the lwc:if syntax supports the ! prefix (e.g. lwc:if={!foo}), we could potentially write a codemod to convert from the old format to the new format.

I also don't understand why an LWC template engine has to prepend every parameter with "lwc".

In general, it's to make it clear which directives are native to the browser and which were added by LWC. (Historically we weren't always consistent about this, e.g. the key directive.) BTW our own onclick is pretty short. 🙂

[nolanlawson]

Closing as this is solved by #2985