If I can query the HTTP API /flows for multiple node-red Instances from a Web App, what library should I integrate in my app to just render the JSON responses to be displayed similar to that of the node-red Editor UI?
You can use the http-in+http response nodes to create an endpoint, it can act like an API. But i could misunderstand your question.
Hi @Shan
there is not a standalone library that renders flows - it's all baked into the heart of the editor.
It has been a long standing wish-list item to have such a library, but it isn't straightforward to achieve as each node defines a lot of its own appearance (colour, icon, label etc). So any standalone library would need to be able to look-up all of the right node definitions to get the appearance right.
This seems related. But nobody cared 
(just kidding).
@Shan, can you share what you are working on exactly? Maybe we can collaborate?
Hi @rko remo, sorry for the delayed reply. I am actually looking into controlling node-RED instances from a single instance, consider it as a federated UI for node-RED instances running on your raspberry pis (plural). let me know if we have overlapping things to work on.
No problem. Did you check out flowforge?
"My" flow viewer would be rather simple. I don't want to deploy or control instances. As the name implies, the viewer allows to view flows, without the need to import it into a running "Node-RED-Server" .. or maybe we gonna create a flow that can read flows as a first step 
.
Furthermore, we would try to tackle the "missing node" problem (probably by just providing the package.json file along with the flow) and ignore configurations at first. You could then browse through multiple flows quickly and maybe even compare differences between versions on a visual level.
sounds like exactly what I had in mind. however I am not sure a package.json along with the flow would help. I am assuming that one needs to install the dependencies in the package.json file and then try to render the information which might be cost-intensive.
I am aware of the structure of the flows file and I was wondering something like d3.js would work to render the flows at the moment.
Adding my 2ct here:
I think I remember a word or a note from @knolleary that there is the intension to remove the dependency to D3 in the Node-RED core. That demands a refactoring of the rendering engine ... which is in essence exactly what you're discussing about. Thus there's the risc that people do (almost) the same task several times.
Following the latest exchange on community contributions I'd propose to enter a slightly different path:
Step 1: Contribute to make the flow rendering engine in the Node-RED core interchangeable - or pluggable. This demands the definition of a consolidated API, and encapsulates the current engine.
Step 2a: Take this encapsulated engine to create your flow viewer.
Step 2b: Support in creating another (then probably D3 free) rendering engine.
Consequentially your efforts directly contribute to the further development of the core, you don't have to re-invent wheels ... and you will be able to stuff your flow viewer with the next-gen rendering engine - once this is done. Win-Win-Win... from my perspective.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
