UI Template: Custom Properties

[joepavitt]

Description

This may take some doing to get "right", but the base philosophy is to build off the great work @Steve-Mcl is doing with #634 whereby we could begin to wrap a ui-template in a subflow to provide a reusable, configurable component in the Node-RED local palette.

A challenge with this is that often, the ui-template is being configured within the Vue component, and doesn't have access to the parent environment variables that would be set at the subflow-level. I see two options here:

1. Expose all Environment Variables to Client

Security alarm bells ringing

2. Custom Properties

To circumvent this, we could introduce the concept of "Custom Properties" which would be a generic list of key:value pairs (of varying types) on the ui-template. It would then be possible within a subflow to bind these to the subflow env vars, and so have a ui-template driven entirely by the subflow properties.

Epic/Story

No response

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

[Steve-Mcl]

My first thought was to pick up env variables addressed in the template using the ast parser but it would be it might be tricky picking them out of the html.

Option 2
If I am reading this right, the proposal is to have an editableList where env vars are linked up to client side object (like how msg is available)?
If so, that can work, but it feels like duplication of effort.

Option 3
It might be possible to use the ast parser to pick env vars out of Vue props or a specifically named data object or via an object prop named env? I would propose only the items specifically named in the template are bound (to subvert option 1)

[joepavitt]

Not just env vars though, anything. Could have strings/numbers/booleans. Just means the general config of a ui-template can live at the node-level, rather than nested inside the Vue template.

Within the Vue template, they'd then be accessible under the existing this.props option, although had been some discussion about us renaming that to be config in another issue as its a better description.

With the generic editable list, that then unlocks the possibility to override those properties with env Vars as you would any other node in a subflow