If I have a Dashboard 2 related issue should I ask that here or start a new thread?
In case the answer is 'here', I am testing widgets in a subflow, which is working well. The question is how do I set the size of the widget? When I click the size it pops up the box with the squares in, but it won't let me select anything. Or is that WIP?
1 Like
I'll suggest starting a dedicated topic for NR4/DB2 so that @Steve-Mcl and @joepavitt can pitch-in without swamping the more general beta discussion.
Will move your post (and this reply) to a new topic to get that started.
1 Like
It was spotted in review, and is still a bit of a WIP. The workaround (at the moment) as that you have to set the width of the widget before moving it into the subflow.
The width sizing widget falls over in the subflow as it's parent group is actually unknown at that point, so the elementSizer() has no maximum to draw from.
Ideally I would like to be able to set the size via subflow properties. I have added that to the issue.
Also, if one has multiple widgets in the subflow I can't see how to define the order in which they appear.
For the element sizer - I suspect that's going to be very very tricky (@Steve-Mcl?) - but I do understand the UX benefits.
The core Node-RED sub-flows would need to support that as an element type, which they do not, and then Dashboard 2.0 would need a way on every elementSizer to be able to say "drive this by an environment variable"
If one has multiple widgets in the subflow I can't see how to define the order in which they appear.
Not sure that's possible right now, one for Steve. Although possibly in the sidebar?
It is super tricky in it's current form.
The sizer cannot (easily) be supplied values via subflow properties. (Visually that is)
I did do a version of this using overrides but i was never fully happy with all the edge cases and considerations of how a node author wrote their edit form (video here)
Of course you can already (today) override any properties you wish by manually modifying the flow and setting the value of the property to ${xxx}
moving forward
A solution that fits more nodes, but requires the node developer to make considerations when designing the edit form is providing typedInputs for all things that could/should be override-able.
So for the sizer, it would be good if we provide the sizer element as a component option in a typedInput. I think it is possible today but not 100% sure. However, we still have options. Like a checkbox that hides the element sizer and shows width and height inputs. Or lose the element sizer altogether and provide 2 separate width and height inputs from the outset.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
