Not sure if the above means that this is only available for props. (and it looks like defaultValue has been changed to default (on save it changes to default)
To my knowledge you cannot currently use default values for vars in widgets. The simplest solution is just to use a basic OR syntax in your expressions: (vars.someVariable || default value). When the variable is undefined at the street of the widget use the OR will return the default value and once the variable has been set by the widget it will return the variable value.
But I am trying to get rid of these annoying messages, so might be a bit more complex:
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_Armed
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_ReadyToArm
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_ErrorBeepTripleBeep
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_EntryGuard
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_ChimeModeOn
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_Exit1
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_Bypass_Group
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: undefined_Cancel
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition5_Armed
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition6_Armed
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition7_Armed
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition8_Armed
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition2_Cancel
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition1_Cancel
15:24:36.979 [WARN ] [se.internal.SseItemStatesEventBuilder] - Attempting to send a state update of an item which doesn't exist: Partition4_Cancel
works just fine. But it’s true that if you have a lot of variable use in your widget it can get tedious and difficult to track.
It never hurts to ask! There quite a few widgets that could be greatly simplified if this were possible. On the other hand, I don’t know if there’s some technical reason why this hasn’t been done up to this point.
There is one other option possible, but it’s a workaround that really only works if you plan on having only one of these widgets on a single page. I said initially that variables in widgets couldn’t have default values, but variables can also be defined on pages so that widgets have access to variables with a more “global” scope and can communicate with each other. These page level variables can have default values set. So if you’re only going to have one widget using the variable, then you can just also define the variable at the page level and give it a default value there.
I believe the same general properties definitions that work for rule templates also work for widgets. In rule templates, you can define a default value using defaultValue: Partition1. I’d be surprised if that doesn’t work but I’m not in a position to test that out at the moment. I’ll try to remember to come back when I get a chance.
uid: demo:default_vars
props:
parameterGroups: []
parameters:
- name: prop1
label: Prop 1
type: TEXT
description: A text prop
defaultValue: This is a default value
tags: []
component: f7-card
config:
title: =(props.prop1 || 'No Default Value Set')
Just for widgets? I think it’s still defaultValue for rule templates. I’m pretty sure I tested that out with my latest rule template I posted a few days ago. Maybe I didn’t.
Right! I forgot about that. That’s true. However it still only applies to properties. There’s still no way that I’ve seen to define variables in the widget config.
uid: demo:default_vars
tags: []
props:
parameters:
- default: This is a default value
description: A text prop
label: Prop 1
name: prop1
required: false
type: TEXT
parameterGroups: []
timestamp: Aug 22, 2022, 5:38:10 PM
component: f7-card
config:
title: =(props.prop1 || 'No Default Value Set')
So changes the defaultValue to default and the output is correct:
I will try and log a GitHUB issue to see if it can be extended to vars as well. Hopefully it will get some traction as that would be WAY beyond my abilities.
Matt’s suggestion is the same thing I mentioned as a possible workaround up above. You don’t define the variable in the widget (widget’s just don’t have the defineVars config property which is the whole crux of this problem). You just define the variable at the top of the page and then reference the variable as you normally would in the widget with the vars object. Because the variable has been defined on the page, the widget references this “global” value instead of using a value local to the widget.
Your second example way you tried is not correct as you are trying to modify the configs of the Oh-cell and not the global pages configs. The first example I do not know why it does not work when I can only see a small snippet of the code. I am using this as a work around and it works for me despite having used the same variable in multiple widgets of the same inserted on the one page.
This is not documented and I found it by searching the forum posts here:
So I have been trying to work with this work around.
It appears however that the variable is only propagated one level sadly.
So if I reference the variable in an oh-cell on a page, the variable is available. However if I try and reference the variable from a widget inside the oh-cell, the variable is no longer available.
So I cannot apply the work around in my use case as my widget needs to be called from an oh-cell otherwise the formatting is all lost and it just does not work anymore.
Oh well. I wonder if it could be added. It’s super handy in rule templates.
