EOS question: Dynamic Choice->Option labels?

[fapnip]

Has anyone found a way to implement dynamic labels for the option buttons on EOS's Choice action?

Manually using <eval>myVariable</eval> as the label text works for the first render of the page using that button, using the value of from myVariable, but if the value of the variable changes, the next time the page is displayed, the button still just shows the old value.

Guessing there's some reactivity issue going on there with values from the fake JavaScript interpreter, but it would be great if the buttons could re-render with new values -- or if we could be given access to a reactive object in the interpreter.

[kerkersklave]

From the looks of it, eval in labels is not an intended feature.
The EOS editor has no user interface to create an eval inside a label, that you can just write it there and it has some effect seems like a bug.
Probably it is parsed and evaluated when a page is created initially and then never again.

[fapnip]

I'm certain it's not intentionally supported, and was surprised it even worked on the first render.

However, it really would be handy if the buttons could be set to re-render if they contain an eval. It would at least be half way to supported then. Having dynamic options would open up so many possibilities.

Is there any known way to force actions/pages to be re-rendered?

[undeniable_denial]

This is brilliant!

I've played with this a little and here is what i found:

• When you nest eval-tags only the innermost gets evaluated
• Every time the page is viewed only one evaluation is done
• If the evaluated value is a string containing an eval tag, you can chain it endlessly.

It is very ugly, but I managed to have a number counting up inside of an eval-labyrinth on an endless button.
https://milovana.com/webteases/showtease.php?id=45164


JSON here:

Spoiler: show

Download

[fapnip]

That's really cool, but unfortunately it seems impossible to do it without displaying the all the nested eval tag noise.

However, it's very interesting that nested tag is executed, and as long as it returns another nested tag, that tag will be executed as well.

[RemiHiyama]

It looks like the code that parses eval tags runs every time the choice is displayed, but it modifies the label text in place, whereas with say tags, it's assigned to a temporary variable.

The function it's run through doesn't do anything -but- handle eval tags, so it's technically not accidental that they work in choices, but they aren't really functional the way they are.

Edit: I figured out a method with less chaff, but unfortunately it's not no chaff.

https://milovana.com/webteases/showteas ... bafac7c8bc

(The button with the funny coloring is part of my attempts to hide the chaff with css, but it turns out that if you have a < character in the contents, it doesn't match the regular expression used for eval tags anymore, so you lose dynamic behavior.)

[fapnip]

Unfortunately, I don't think there's any way to get around the noise without @seraph0x or the like making changes to their render code.

Really would be handy to have this working though. Just to display nine simple multiple choice buttons for answers to randomly generated math problems capped at a maximum value of 99, like I did here, I had to add 100 buttons, 0 to 99 -- and that's all they can do. Input prompts really aren't a workable solution if you intend to support mobile users at all.