Today TW 5.2.1 prerelease got an exciting update
Set Multiple Variables at Single Step and Show Edit Preview per Tiddler
See these two new features
5 Likes
I now want to rewrite most of my plugins to use $let.
2 Likes
New Feature 5.2.1p
ActionSetMultipleFieldsWidget
https://tiddlywiki.com/prerelease/#ActionSetMultipleFieldsWidget
Gotot:https://tiddlywiki.com/prerelease/
and try this in a new tiddler
<$button>Multiple set
<$action-setmultiplefields $tiddler="Test" $fields="[range[1,4]pad[2]addprefix[field]]" $values="One Two Three Four">>/>
Click me!
</$button>
You get
Wow, amazing!
This means create several fields and set values at one step!
3 Likes
I’m wondering what happens when there is a field/value mismatch.
It appears that something needs tweaking (from the site) 
This sounds exciting! Is the new LetWidget like the VarsWidget where if you attempt to store a titlelist thru filtered transclusion it will only store the first variable?
<$vars tagged={{{[tag[foo]]}}} >
Will only store the first title with tag foo.
If you encapsualte the transclusion with """...""" then it seems to capture the full transclusion output.
What am I missing? This seems like something that is already pretty easy to do in TW. You will probably always need to define one or more variables outside the widget in order to make sure that fields and values match. So the code you write won’t be that much simpler.
Edit: I’m referring to the action-setmultiplefields widget.
LetWidget - exciting news!
Is the $vars widget better in any way, or would it make sense to consider the $vars widget deprecated with the new $let widget?
What is the reasoning behind creating a new “let” widget instead of just upgrading the current “vars” widget ?
Doesn’t adding another widget in the mix (set vs vars vs let) complicate things going forward?
The big difference between the “let” widget and the “vars” widget is that with the former the variables are assigned in order, one at a time, so that successive assignments can depend on previous results.
For example, here’s a way to swap two variables:
<$let temp=<<a>> a=<<b>> b=<<temp>>>
...
</$let>
That wouldn’t work with the “vars” widget because the assignments are all done at once, so “b” would be assigned the parent value of “temp”.
The new behaviour is not backwards compatible, sadly.
In almost all cases it now makes sense to use “let” in preference to “vars” because it allows for more concise code when assigning multiple variables.
4 Likes
Given our commitment to backwards compatibility, this is how we have to make progress: adding new functionality and deprecating old.
When to add such features is a trade off, but in this case the advantages of the “let” widget are clear, and the only real disadvantage is that it is not backwards compatible with the “vars” widget for certain extreme edge cases. In ordinary, everyday use, they are interchangeable, with the addition of “special powers” in the “let” widget.
2 Likes
Yes that is correct. Only the first title from the filter output will be saved in the variable. This behaviour comes from how filtered transclusions for widget attributes works, and is common across all widgets.
1 Like
I like “let” because it is shorter than “vars”, and because I am still a huge fan of the Basic programming language, so “let” tugs at my heartstrings.
I can see how most folk will appreciate “concise” code. That seems popular in javascript, c++, etc.
Me, I rely on seeing the visual cues that a variable does depend on something that happened before. So when I see two subsequent "<vars>" (me in the near future: two subsequent "<let>"), it is a grab-me-by-the-jugular heads-up that I’ve got some variable dependency going on.
Well, keeping in mind I look upon that with at least two cognitive disabilities, which really impact how I process information (I need my guardrails.)
All of that aside, are there any performance considerations re vars vs let ?
Not yet mentioned in this thread is the SetMultipleVariablesWidget which @jeremyruston raised elsewhere, which has some serious possibilities.
This is a quick brain dump - please ignore if it does not make sense to you. I will share a more concreate example later.
Unlike set /vars and let, the variable/values pairs can respond to filters, including the number of variables. I see the initial value here is adding this to and wrapping the view template so variables and values can be preset before the view template, according to complex conditions within the wiki or relating to the current tiddler.
This overcomes a functional limitation built into the current view template mechaisium. Why would this be important? because when you have a widget that needs open and close eg vars and set, you need to wrap the view template in it, if you want these to be active inside the view template body, This allows you to pre-wrap the view template and introduce variables and value settings programaticaly.
1 Like