In your specific case, almost nothing — but we could construct a hypothetical where it would make a difference, due to the way $list works. First, some background information:
- As you’re probably aware, the “default” value of
<<currentTiddler>> is the title of the tiddler you’re currently viewing.
- However, also by default,
<<currentTiddler>> is redefined within the context of a $list (i.e. the widget’s content) to refer to each result. For instance:
code used above
<$list filter="[tag[HelloThere]]">
`<<currentTiddler>>` = `{{!!title}}` = <$text text=<<currentTiddler>> /><br>
</$list>
Because the filter [tag[HelloThere]] produces a new list of titles, we lose the original value of <<currentTiddler>> within the context of the list.
To preserve the original value of <<currentTiddler>> within the $list content, we can use the variable attribute of $list to nominate a variable name that will be used for each result:
code used above
`<<currentTiddler>>`: <<currentTiddler>>
`{{!!title}}`: {{!!title}}
<$list filter="[tag[HelloThere]]" variable="myVar">
`<<myVar>>` = <$text text=<<myVar>> />;
`<<currentTiddler>>` = `{{!!title}}` = <$text text=<<currentTiddler>> /><br>
</$list>
The conditional shortcut syntax is a shortcut for this variable-definition step. When you type this…
<% if [<currentTiddler>tiddlertype[Landing Page]] %>
... displayed only if the above filter produces at least one result ...
<% endif %>
… behind the scenes, it’s converted to a $list widget that looks like this:
<$list filter="[<currentTiddler>tiddlertype[Landing Page]]" variable="condition" limit="1">
... displayed only if the above filter produces at least one result ...
</$list>
Since the conditional shortcut syntax always generates a $list with variable="condition", you don’t have to worry about selecting an alternate variable: the first output (see limit="1") of the filter is always available within the conditional as <<condition>>, and <<currentTiddler>> always retains its original value. So Scott’s suggestion is a good one as far as “best practice” is concerned, because a) you don’t have to worry about losing the original context of <<currentTiddler>>, and b) the <% if %> syntax makes it more visually obvious that this piece of code is being used to display content conditionally, not to iterate over a number of titles in a list.
However, as I’d nodded to in my edit above…
His suggested alternative — though very sound generally speaking — doesn’t make any material difference in this instance because of the specific filter you used: [<currentTiddler>tiddlertype[Landing Page]]
Here, the sole input is <<currentTiddler>>, and the sole operator is (field:)tiddlertype. field:.. belongs to a group of what I like to call “pass-through” operators, along with other operators like search and has. Pass-through operators don’t transform their input values in any way; they simply filter out those titles that don’t meet the specified condition. Thus, if <<currentTiddler>> has the tiddlertype field value “Landing Page”, [<currentTiddler>tiddlertype[Landing Page]] = <<currentTiddler>>… and while the $list widget redefines <<currentTiddler>>, its effective value doesn’t change.
Final takeaway: In this case, you should feel free to use either your original $list or Scott’s <% if %> equivalent. When working with more complex filters that transform their input values (e.g. get[fieldname] or split[ ] or multiply[5]), you may need to use either a $list with a named variable or an <% if ... %> construction if you will need access to the original value of <<currentTiddler>> inside a filtered segment.
