Any Documentation Around for Valid Javascript in Expressions in Widgets

Hi,
I’m starting to look at some redesign work on my frontend and I’m struggling a little on understanding which javascript functionality can be used in UI widgets.
For example; in a repeater I see you can do something like:

loop.item.tags.includes("TagName")

However, something a little more complex like trying to check if any elements of an array exist as a tag fails:

props.showSensors.split(",").some(element => loop.item.tags.includes(element))

Error I get is something like:

Expected comma at character 42

So, I’m guessing you can’t have javascript expressions like this in widgets.
It’s difficult to know what you can and can’t do in widgets, so I was wondering if there’s any sort of rough guide.

Thanks,
Richie

See Building Pages - Components & Widgets | openHAB

The repeater widget has a few more options to build and iterate over the list. oh-repeater - Repeater | openHAB

Nowhere is any arbitrary JavaScript allowed though. Only these subsets.

1 Like

The widgets use the expression-eval library which you can find here.

That’s based on jsep, and there you can find a very brief help doc.

The issue with your code is the arrow function. That’s not permitted in the expression-eval library. Alas, no function declarations of any kind are permitted, as far as I can tell, which makes many of the Array methods (which are permitted) useless.

I’ve been meaning to start up a github issue to discuss this, there are some options that would improve what’s allowed in the expressions.

4 Likes

Here’s a github feature request:

1 Like

You can have a look at the unit tests of the expression-eval library to figure out roughly what’s possible:

(ignore the last two, ‘this’ and custom operators)

The identifiers used in the tests refer to the ‘context’ defined here:

The actual context you have at your disposal is documented in https://www.openhab.org/docs/ui/building-pages.html#dynamically-configuring-components-with-expressions

1 Like

Now that I think of it, defining a custom operator like

@'ItemName'

which would be equivalent to:

items['ItemName'].displayState || items['ItemName'].state

(which has been reported as a pain point several times)

might prove very useful? :thinking:

3 Likes

This is inspired! If you don’t mind, I’ll take a shot at this too while I’m looking into the other parser improvements.

3 Likes

FYI: Arrow functions (along with the new @ operator) now work in the latest snapshot version. Although be advised, if you upgrade to a snapshot at the moment there still seems to be a small issue with authentication.

2 Likes