[blockly] change event attributes, add return block

[stefan-hoehn]

Depends on: openhab/openhab-addons#19443

The event object/attributes in script actions and conditions is now the same as in JSRule and Rule Builder.
Backwards compatibility will be retained for some time, though it is advised to adjust, which is done in this PR according to:
https://github.com/openhab/openhab-js/blob/51f164dc9f11a29e6223e24268848aa8f0be168f/src/rules/rules.js#L471

Additionally a new return block was added to the "Run & Process" category with return parameter.

1. The block without a return parameter is a nice improvement to easily leave a script without using non-elegant if/else statements. Bei adding the return statement the script is immediately ended. In this case the return parameter is not important.
2. By adding a return parameter (in particular true or false) this can be used for condition, e.g. by using this condition:

which can implemented by using an inline blockly script that evaluates to true or false.

[relativeci]

#3495 Bundle Size — 11.38MiB (~+0.01%).

5585292(current) vs f0117c8 main#3490(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   1 change

	Current #3495	Baseline #3490
Initial JS	2.01MiB	2.01MiB
Initial CSS	577.56KiB	577.56KiB
Cache Invalidation	18.48%	17.7%
Chunks	254	254
Assets	277	277
Modules	3036	3036
Duplicate Modules	163	163
Duplicate Code	1.85%	1.85%
Packages	99	99
Duplicate Packages	2	2

Bundle size by type   1 change 1 regression

	Current #3495	Baseline #3490
JS	9.59MiB (+0.01%)	9.59MiB
CSS	875.33KiB	875.33KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	140.74KiB	140.74KiB
HTML	1.39KiB	1.39KiB
Other	871B	871B

Bundle analysis report Branch stefan-hoehn:blockly_migrate_eve... Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[rkoshak]

When you add the docs, make sure to make it clear that return can only be used when the wrapper is enabled in the JS Scripting configs (MainUI -> Settings -> JS Scripting.

[florian-h05]

Our idea was to make blockly automatically set the directive to enable the wrapper when return is used.

[stefan-hoehn]

you can actually see this in line 397 that creates "use wrapper" in the code.

[rkoshak]

Is that something that can be done from a JS script? For example a rule template?

I think I've found ways for my templates to work around that but knowing it's possible might prove helpful in the future.

[florian-h05]

Is that something that can be done from a JS script? For example a rule template?

I haven't written docs for that yet, but the 'use wrapper' directive can be used in any JavaScript condition in the UI.
It just has to be first or second line, i.e. top of the script.
For actions, you don't need it, there the wrapper is always on (unless you explictly disable it, but that's mainly implemented for the case there is any unexpected issue).

[rkoshak]

So I can enable the wrapper but not disable the wrapper? I'm not trying to argue about anything, just understand in case it's helpful to me in the rule templates and so I understand how it works in Blockly so I can help on the forum better.

And don't you have actions and conditions backwards in your description. I thought the decision was to always enable it for Conditions and optionally enable it for Actions based on the add-on property. I could be remembering backwards, but that was what I thought. The reasoning was having the return statement in Conditions was worth keeping it always enabled, and doing so had minimal impact.

[stefan-hoehn]

Not sure if it helps. As soon as Blockly adds one of these blocks, it adds "'use wrapper'" to the top of the script that it generates.

[florian-h05]

You can also disable it, there are three ways of using the wrapper:

• 'use wrapper'
• 'use wrapper=true'
• 'use wrapper=false'

The first two are equivalent.

And don't you have actions and conditions backwards in your description. I thought the decision was to always enable it for Conditions and optionally enable it for Actions based on the add-on property. I could be remembering backwards, but that was what I thought. The reasoning was having the return statement in Conditions was worth keeping it always enabled, and doing so had minimal impact.

I think you have to switch actions and conditions there. For actions, it is always enabled, since it has minimal to no impact, for conditions, there is the global add-on setting and the use wrapper directive to control the behaviour.

[rkoshak]

You can also disable it, there are three ways of using the wrapper:

Excellent! Thanks!