Add design note for UI Module

[HiroyasuNishiyama]

Node-RED Dashboard is convenient tool for creating GUIs. But creating complex dashboard screen is difficult with current Node-RED Dashboard because the screen should be created by combining basic set of dashboard widgets.
This design note is aimed at addressing this problem by providing UI module that creates reusable UI components consisting of existing UI widgets.

[dceejay]

Possible actions for Dashboard groups in groups capability

(Notes from whiteboard)

Rather than a new ui_module node we propose that ui_groups be extended to allow ui_group nodes to include other nested ui_group nodes. In order to allow this the following sub-tasks are required.

• A) Config node allow select node for ui

• B) Create/modify layout tool to layout single group

  • Add button to ui_group edit dialogue to open this layout tool

• C1) Move Widget Order property into Group Node.

• C2) Modify layout tool to allow Group within group.

• C3) Group may have Heigh property added.

• D) Change sidebar to support group in group

  • Don't add widgets from subflow to tree
  • Do add group from subflow (fixed size only)

• D) When widgets added to subflow disable setting of group/tab

  • Generate Group node (add and auto assign widgets)

[KazuhiroItoh]

I updated design note for UI Module.

[knolleary]

I'm on vacation so cannot look at this until next week, but can you please provide a summary of the updates you have made?

[KazuhiroItoh]

Thank you for confirmation.
Used by the UI module, SUBFLOW instantiates the nodes defined in the template to generate the nodes.
Since the widget node has layout information for each node definition, it cannot be arranged correctly when multiple instances are created from the SUBFLOW template.
Therefore, I changed it to use two configuration nodes, template and instance.
Also, the original design note was the implementation in the Node-RED runtime/editor, but I changed to implementing the Node-RED dashboard.

[KazuhiroItoh]

In order to support the UI-Module function, two functions that need to be added to Node-RED added to design notes.

1. Acquisition of subflow information
2. Remapping node ID during flow import

[KazuhiroItoh]

1. Acquisition of subflow information

I considered countermeasures for this matter.
Reference implementation: get subflow info

Measures are taken so that the subflow instance to which the widget belongs can be referred to when the widget is instantiated.
The content is the same as the modification of the design note, but added the process to delete unnecessary instances after the widget is generated.

If there is no problem, I would like to issue a PR.
Please check.
Thank you and best regards.

[knolleary]

Thanks @KazuhiroItoh.

I have read through this design a couple times and I think I see what the ui_subgroup_t and ui_subgroup_i nodes are. I was expecting to see something called ui_module given the name of the design. Not a massive fan of the _i and _t naming... but don't have anything better to suggest.

I need to understand a bit more about why you need access to the subflow instance information. The design doesn't give the details and I can't quite see it.

[knolleary]

Can you explain why this is needed? Why do we need two different ways for the UI_GROUP to be set? Is there a particular scenario it addresses?

[KazuhiroItoh]

Thank you for checking.
By using _UI_GROUP, I would like to be able to use the UI Module with the same operation as a widget.
For UI Module users, it's easy to understand because it can be treated like a widget.

However, the creator of the UI Module (subflow) must add the _UI_GROUP property to the subflow.
The subflow also needs the ability to set the Config node in the property.
Therefore, it is proposed as an optional function.

[knolleary]

As above - why is this needed?

[KazuhiroItoh]

By linking the value of _UI_GROUP to ui_subgroup_i, you can omit the setting of ui_group.

[knolleary]

Exactly what information is needed from the subflow instance?

Is it the subflow env properties? If so, they will already be visible to the node as environment variables - this._flow.getSetting("...") can be used to access its value in the subflow.

[KazuhiroItoh]

I want to get the ID information of the subflow instance to which the widget being generated belongs.
For widgets nested within a subflow, IDs are required up to the parent subflow.
Specifically, this is the value set for the subflow path.

Example:
"fda95d7e.fb54/3b5a5523.01d41a/d771a7ef.6586e8/cc844746.a516f8"

In node-red-dashbord ui.js#function add(opt), I want to use the above value when arranging the widget, so I considered the idea of getting the subflow instance from the value of opt.node.z.
I checked the argument opt, but it seems that the '._flow' you pointed out does not exist.

[KazuhiroItoh]

I would appreciate it if you could consider this matter.

Reference implementation: get subflow info

I recognize that it is necessary to make corrections based on this measure in order to acquire subflow information in the process of UI node generation.

The following usage is assumed.

node-red-dashboard#ui.js:

function add(opt) {
var subflow = nodes.getNode(opt.node.z);