Tiddlywiki5: Introduce shortcut syntax for transclusion passing parameters via variables

Created on 4 Dec 2020  路  8Comments  路  Source: Jermolene/TiddlyWiki5

There has been some recent discussion (and the subsequent PR #5195) about the poor parsing performance of macro calls compared to transclusions. In particular, the result of parsing each tiddler is cached and reused next time if the tiddler hasn't changed (the same technique can't be used for macro calls because they are not global but local to the widget tree).

So, we should promote the judicious use of this technique. However currently, it is inconvenient to pass parameters to transclusions as a separate <$set> or <$vars> widget needs to be used.

It is proposed to introduce a shortcut wikitext syntax for passing parameters via variables when transcluding a tiddler. For example:

{{tiddler||template} myvar=<<value>> }

Would be equivalent to:

<$vars myvar=<<value>>>
{{tiddler||template}}
</$vars>

(We may want to allow : to be used as a synonym for = for consistency with the existing macro call syntax).

We may also want to support positional parameters that do not need to be named when they are called:

{{tiddler||template} <<value>> }

In such a case, the target tiddler would have to define a parameters field containing an ordered list of the parameter names it requires, and then the provided value would be assigned to the correct variable before the transclusion.

Most helpful comment

@Jermolene Overall I am very much for this proposal.

I am somewhat unsure about the _positional parameters_ and the _parameters field_ in the target tiddler. It would be introducing an entirely new concept and cognitive overhead for users. Unless it offers some advantage that I am not thinking of at the moment I would prefer that _named parameters_ be used. This way the same template tiddler could be transcluded with the new syntax, or the old fashioned way using a vars widget. Also it would be one less new concept for users to learn.

All 8 comments

@Jermolene Overall I am very much for this proposal.

I am somewhat unsure about the _positional parameters_ and the _parameters field_ in the target tiddler. It would be introducing an entirely new concept and cognitive overhead for users. Unless it offers some advantage that I am not thinking of at the moment I would prefer that _named parameters_ be used. This way the same template tiddler could be transcluded with the new syntax, or the old fashioned way using a vars widget. Also it would be one less new concept for users to learn.

Perhaps we also need to document the performance advantage of transclusions over macros at https://tiddlywiki.com/#Performance

I am somewhat unsure about the positional parameters and the parameters field in the target tiddler.

+1

I think we should stick with named params only.

What we need at a minimum is at least one, possible parameter in the short form and widget transclude, allowing other custom parameter's and dealing with arbitrary names and positioning of parameter's may be desirable (as discussed in this thread) but I believe 90% of the increased functionality becomes available, with only one parameter being available. It could be used as a switch.

The transclusion variable used inside a transcluded template returns a little more information. It can be used to get the name of the transcluded/transcluding tiddler, but you have to parse the output of the transclusion variable. Setting a variable for this "code tiddler" would be helpful.

In effect the currentTiddler value is currently the only parameter "passed" with a transclusion, even just a single additional parameter would allow a template to respond. Currently I have a workaround, in a number of templates, that I invoke with {{paramname||templatename}} where the currentTiddler variable can be used as a parameter, and if I need access to the currentTiddler, I get it from the Story Tiddler variable.

Since transclusions can access variables and other values, all we need is a simple way to pass a value when wanting to add a switch mechaisium inside a transclusion. For example
{{tiddlername||templatename:switch}}eg <<switch>> may be equal to view or edit and can be used to change the way the template responds. and the switch variable set to that value. Passing a filter as a parameter would also be helpful.

This may allow transclusions to be used more often and more efficiently than macros.

It may be easy may be to to update the transclude widget such that it's parameter's varname=value are converted to variables before transclusion. This long form could be used when there is more complex parameter requirements but a simple pre-named variable made available in the short form eg <<switch>> or <<param>>

Regards
Tony

Hi @AnthonyMuscio I'm not clear if you're agreeing with the proposal in the OP, suggesting additional features or making an entirely different proposal. Comments like "This may allow transclusions to be used more often and more efficiently than macros" are confusing because (a) it's not clear what "this" refers to and (b) it's the motivation given in the OP for this proposal. Are you agreeing or making a different point?

@Jermolene ... did you create any code already?

@Jermolene ... did you create any code already?

No I haven't looked at this further yet.

I think that would be a nice and understandable syntax.

{{tiddler||template} myvar=<<value>> }

We may also consider this

{{{"filter syntax here"} myvar=<<value>> }}

to have "feature" parity the transclude widget needs the same mechanism for additional variables, which leads us to the same problem we discussed at: #5026 and #5052

I did implement it for my wl-radio-widget like this: https://github.com/wikilabs/plugins/blob/master/wikilabs/custom-markup/tiddlers/widgets/wl-radio-widget.js ...

Which is 1 of the versions we discussed ... It turns out to be very usable and easy to read and understand. see: https://wikilabs.github.io/editions/custom-markup/#test-wl-radio

Was this page helpful?
0 / 5 - 0 ratings

Related issues

saqimtiaz picture saqimtiaz  路  5Comments

twMat picture twMat  路  5Comments

KendrickLamarck picture KendrickLamarck  路  4Comments

diego898 picture diego898  路  5Comments

TiddlyTweeter picture TiddlyTweeter  路  6Comments