You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A common problem with importing/exporting flows is not knowing if additional modules are required to be installed. The user is left on their own to figure it out.
There are two possible solutions here.
Option 1
Include the module name in the exported node object, for example: m="node-red-node-random"
The downside of this approach is it greatly inflates the flow json with a lot of redundant information. If you have 100 nodes of the same type, you have 100 copies of the module name.
This isn't terrible, but it isn't great.
Option 2
Make use of the global-config config node introduced in 3.x to include a module manifest.
This is a more attractive option - as it could afford to include more meta data such as module version.
Ideally there should only be one global-config node in a deployed set of flows. To keep true to that, the editor would have to properly merge an imported global-config node with what is already there. But we'd also want to make sure both editor and runtime work okay if there are multiple nodes present (I think it does... but not sure I've explicitly tested for that).
UX
When importing a flow containing module meta-data (regardless of the approach chosen above), the editor should then prompt if there are modules that need installing. The user should then be able to pick what to do next:
cancel the import
one-click install of the missing modules
let the user resolve it manually
The apis for installing modules are optimised for installing one at a time. We may want to look at enabling installing multiple modules in one api call - so we run npm once overall and not once per module.
The text was updated successfully, but these errors were encountered:
I like option 2 because it's global and centralized. For the UX it seems complete to me.
Using this node can also allow the addition of various data. For example, when I export a flow, I add the machine name to the name of my first flow to identify which flow it is (of course the file name contains it too). Now it will be global-config which will contain this information. We can consider adding a version, a description... I don't know if it's useful but it could contain information from the FlowFuse snapshot. It's not part of this request but could it be the subject of an extension?
A common problem with importing/exporting flows is not knowing if additional modules are required to be installed. The user is left on their own to figure it out.
There are two possible solutions here.
Option 1
Include the module name in the exported node object, for example:
m="node-red-node-random"
The downside of this approach is it greatly inflates the flow json with a lot of redundant information. If you have 100 nodes of the same type, you have 100 copies of the module name.
This isn't terrible, but it isn't great.
Option 2
Make use of the
global-config
config node introduced in 3.x to include a module manifest.This is a more attractive option - as it could afford to include more meta data such as module version.
Ideally there should only be one
global-config
node in a deployed set of flows. To keep true to that, the editor would have to properly merge an importedglobal-config
node with what is already there. But we'd also want to make sure both editor and runtime work okay if there are multiple nodes present (I think it does... but not sure I've explicitly tested for that).UX
When importing a flow containing module meta-data (regardless of the approach chosen above), the editor should then prompt if there are modules that need installing. The user should then be able to pick what to do next:
The apis for installing modules are optimised for installing one at a time. We may want to look at enabling installing multiple modules in one api call - so we run npm once overall and not once per module.
The text was updated successfully, but these errors were encountered: