Please add an early exit feature for latte templates

[BernhardBaumrock]

• Explain your intentions

As explained in this forum question I'd need an early exit feature in latte templates: https://forum.nette.org/en/35172-early-exit-in-latte-template-file

This follows the guard clause instead of if/else-nesting, see https://www.youtube.com/watch?v=EumXak7TyQ0 why this can be good for reducing code complexity and making it easier to read and maintain.

• It's up to you to make a strong case to convince the project's developers of the merits of this feature

I've built a page builder for the ProcessWire CMS that looks like this:

These content blocks consist of a controller file and a view file. The controller file is PHP (eg Gallery.php), the view file is LATTE (eg Gallery.latte).

A simple view file could look like this:

<h1>{$block->headline}</h1>
<div n:inner-foreach="$block->images() as $img">
   ...
</div>

Now what I'd like to do is to only render the view file if certain conditions are met. In this example it would be great to only render the gallery view file if the block has at least one uploaded image.

{returnif !$block->images()->count()}
<h1>{$block->headline}</h1>
<div n:inner-foreach="$block->images() as $img">
   ...
</div>

Without this feature I need to wrap my view markup in an if condition:

{if $block->images()->count()}
  <h1>{$block->headline}</h1>
  <div n:inner-foreach="$block->images() as $img">
     ...
  </div>
{/if}

Thx for considering :)

[MartinMystikJonas]

Why not simply use plain if? Like this:

{if $block->images()->count()}
  <h1>{$block->headline}</h1>
  <div n:inner-foreach="$block->images() as $img">
     ...
  </div>
{/if}

[dg]

I would probably use skipIf rather than returnIf…

[BernhardBaumrock]

@MartinMystikJonas good point, didn't think of that. IMHO it's ugly, so it's partly just a personal preference :) But there are often cases where early exists are a lot cleaner than if/else/and/or...

{returnIf !$block->images()->count()}
{returnIf $block->settings->foo}
{returnIf $block->settings->bar AND $block->title == 'bar'}
<h1>{$block->headline}</h1>
<div n:inner-foreach="$block->images() as $img">
   ...
</div>

Also it does not add unnecessary indentation etc. It's the same as having n:if where you could also wrap the tag in {if}...{/if} but n:if or n:tag-if producing much cleaner code!

[dakur]

@dg I would expect skipIf to be a pair tag that bounds what should be skipped. Maybe stopIf would be an option? Or maybe breakIf, even though it's not a loop. returnIf on the other hand best fits to the nature of a template – that it's a function.

[BernhardBaumrock]

@dakur that's exactly what skipIf should NOT be. As you describe it {skipIf} would just be the opposite of {if} and that's not what I want. I'm talking of a new concept that skips rendering of the whole latte file if a condition is met. So {skipIf} would not have any closing tag by design.

[dakur]

@BernhardBaumrock I know, I understood your proposal. I'm discussing the word to be used and its sense – how it's read and understood in the code.

Word "skip" in my opinion implies that it will be further defined (inside of the tag) what should be skipped, because skipping means that you will continue somewhere further (below), whereas "return"/"break"/"stop" clearly says that the code execution stops and doesn't continue for the rest of the file.

Example – if I see this code:

{returnIf !$block->images()->count()}
<h1>{$block->headline}</h1>
<div n:inner-foreach="$block->images() as $img">
   ...
</div>

I clearly understand that if condition is not met, whole template ends rendering. While if I see

{skipIf !$block->images()->count()}
<h1>{$block->headline}</h1>
<div n:inner-foreach="$block->images() as $img">
   ...
</div>

a question arises: "wait, but what should be skipped? where will it continue?"

At least that's my perception of it.

[BernhardBaumrock]

Ah, thx @dakur good point. I think that will also fit better into the principle of latte being very close to plain PHP and not a different language. +1 for returnIf :)

[dg]

For me it was about reusing existing tag in a new context https://latte.nette.org/en/tags#toc-continueif-skipif-breakif

[dakur]

In that context, skipIf seems like a solution for a particular problem – being able to continueIf while preserving the counter. But still, the loop gives a sense of the context – what is being skipped. When the context is whole template file, I think it's not so obvious. I can see more similarity to breakIf than to skipIf.

But it's just wording, the point is the functionality of course, words can be changed any later. :-)

[milo]

@dg What about somehow extend the ifContent macro? To be able hide parents/siblings?

[dg]

I see it exactly the opposite :-) The term return doesn't mean anything to me in the context of templates. What to return? On the contrary, it is common to use skip to … ehm … skipping https://phpunit.readthedocs.io/en/9.5/incomplete-and-skipped-tests.html#skipping-tests https://maven.apache.org/plugins-archives/maven-surefire-plugin-2.12.4/examples/skipping-test.html https://github.com/cypress-io/cypress-skip-test etc

@milo it is not about content, but about your conditions

[dakur]

In tests, you skip whole test, you don't say "skip" from the middle of the test. But it's true that Bernhard posted a use-case with skip at the beginning, not in the middle, so I give up. 🙂

[dg]

I understood it from the beginning as early exit, i.e. ending in header.

Maybe we could also use endIf.

[BernhardBaumrock]

For me none of skipIf, breakIf or endIf feels right. skipIf and breakIf do belong to loops. And endIf belongs to a preceeding {if}.

If you don't like returnIf, what about exitIf?

{exitIf !$block->images()->count()}
{exitIf $block->settings->foo}
{exitIf $block->settings->bar AND $block->title == 'bar'}
<h1>{$block->headline}</h1>
<div n:inner-foreach="$block->images() as $img">
   ...
</div>