Open joepavitt opened 6 months ago
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)
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
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 https://github.com/FlowFuse/node-red-dashboard/pull/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 aui-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