Well there you go. Every day is a school day 
1 Like
Cheers! It's fun experiment around and seeing where this will lead... (I was thinking about a visual diff using AR/VR glasses!)
Yep I just wanted to get something up and running, so I naïvely thought this would be simple ... and it was until the details popped up their dirty little heads.
True but it's also very difficult to go through 5k+ lines of JS code ... but I did find how to do the labels for groups ... on line 5555! I mean you are perfectly correct but the Node-RED codebase also has interaction code (i.e. for mouse clicks and mouses overs etc) and layers in the SVG that I don't need and it uses d3 which I don't want to include. I am currently using jQuery but I really want to have a JS standalone plugin for easy embedding of Node-RED flows, so I would want to remove the dependency on jQuery.
And honestly, I did approach this with a naïve idea that it would easy 
turns out there are many edge cases that I can either try to read out of the Node-RED code or experiment and find myself - where is the most learnings to be made? Edge cases are the hardest to discover and the hardest to read out of code - my personal experience!
2 Likes
Just for those who come after me, how to check the (x,y) coordinates and what they mean?
Use Export!
Move the object to the top-left and export the flow. Check the (x,y) values. Notice for the group, x,y are top-left corner (5,5) while for the node they are (115,20) - midpoint. For link-in/link-outs they are midpoints for junctions they are top-left because the rect of the junction is translated by (-5,5).
BTW groups don't always have w and h (see screenshot under the x,y values) values - I've seen some groups that only have w or neither. Hence I had to compute the width and height of a group rectangle using bounding boxes.
Group:
Node:
The question at the end of the post: does this change in anyway when using v2 of the flows.json? Or better asked: where does v2 get used? I only notice that there was v2 when I was using the api to export flows.
So here is the version 5 which now has labels for groups and multi-line labels at that! Also for nodes mutli-line now works. I actually did copy that code from the Node-RED source. The core plugin code is also there.
This still does have the decoration of the input and output connectors nor the correct number of outputs. But that's not rocket science. I'll now build a small demo of inlining the result if a code-block with plugin name is detected, i.e., the use-case I was trying to scratch with my itch.
1 Like
This is looking really good. Great progress.
Thinking ahead a bit - do you see this being packaged into a NPM module that users can import (in a function node) or run via CLI to generate SVGs from flows?
1 Like
If someone wishes to do that, why not! I generate my SVGs using Node-RED - dogfooding by using (shameless plug) my own screenshot node ... hm questionable whether I need that now 
My actual use-case I had in mind is demonstrated by this page - the embedding of flows.json as code blocks that get replaced by SVG images if a language (in this case noderedjson) is added to the codeblock.
That still uses jQuery because I can't kick the habit, but in the long term I would like to have a version that uses pure Javascript so that any code hoster can add that to their plugin collection, e.g., GitHub.
2 Likes
Forgot to say, that without Node-RED, I won't have been that progressive, i.e., it's really cool how easy it is to play around this with stuff using Node-RED! My flows are starting to flow over my head 
Cheers for Node-RED 
1 Like
That really does make your work an ideal candidate for an importable NPM module (esm for web based use - like you did, cjs for those wanting to embed it into a node-red flow/function-node/contrib-node or even automate it via cli)
I've made some updates of the demo page to provide some more context and explanation for those not familiar with backticks in markdown.
I also gave a motivational overview, i.e. why I did this and an explanation how to include this in your own page. I also - the best big - moved the flows into view, i.e. made the svg viewBox fit to the bounding box of the content. So no more scrolling looking for flows!
I leave it here for the moment and get on doing something else
Also I think doing something here, for example generating a css with colours or urls to images or/and a js with node type-colour mappings along with the catalogue would make the plugin much more useful than harding coding those details into the javascript that I've created.
Just working on the inputs/output decorations and discovered something interesting about inputs:
[
{
"id": "0d76380a09bee3c5",
"type": "comment",
"z": "3b1289d7ccf9cb0f",
"name": "",
"info": "",
"x": 389,
"y": 657,
"wires": []
},
{
"id": "51cb3ec7d26ad00e",
"type": "http response",
"z": "3b1289d7ccf9cb0f",
"name": "",
"statusCode": "",
"headers": {},
"x": 397,
"y": 705,
"wires": []
}
]
That is a comment and a http response node in json representation. The comment node has zero inputs, the http response node has 1 input. From the flows.json representation there is no indication of that. There seems to be some magic going on. Is there a list of nodes that have "implicit" inputs? I assumed that if inputs attribute is zero or non existent, then there is no input but sometimes there.
Outputs are easy: wires.length > 0 will indicate whether a node has outputs and how many it has.
There is no magic 
This is one of those things (like the icon and whether it has a button) that are defined by the nodes code, and is not reflected the flow JSON.
See here: HTML File : Node-RED - there is a property named inputs
For the sake of simplicity at this point, I would hard code what you know about the core nodes (e.g. that a comment has zero inputs, an inject has a button etc) and everything else has 1 input & no button.
When I get time, I am going to look at the data populated in the catalogue and see if we can update its routines to grab some of this meta info and store it in the catalogue entry (for this kind of use).
Yep upon reflection I realised that it would be the case that the editor knows from the package details.
What I'm going to do is check all the wires from all nodes beforehand, creating a list of nodes that receive input. After that it will zero input nodes get nothing and those with inputs have decoration. So it will be based on the definition of the individual flow defines the decoration.
After all, nodes that have inputs but don't receive input within the flow are "orphans" to a certain extent.
Request for Comment: Triangle v. Rectangle!
I have updated the example page Replacing Node-RED flow codeblocks with flow images. | Open Mind Map Blog with the input/output decorators. But I've done something slightly differently ....
I've used triangles instead of rectangles for the decoration. The reason I did this was because when one looks at a "static" flow image and one isn't interact with it, one does not know in which direction the data flows. Especially for people who have zero experience with Node-RED (as with my better half who made me realise this), the image has zero indication for the direction of flow.
Sure if one has used Node-RED then: left is input, right is output - you realise this because you connect things. But for those who have no experience, they don't have this learning.
So I thought I'd use triangles to indicate data flow direction. The triangle is about the same size and same colour as the rectangle, only it indicates the direction of data flow.
Thoughts || Suggestions?
versus:
Proposal: Let the output(s) stay rectangles; make the input a triangle. This should give a visual indication where data is entering a node ... and keeps the (sometimes) busy output interface as clean as in Node-RED.
I think it shouldn't have any graphical diffences. Otherwise the name Flow Viewer is not valid anymore.
1 Like
Ideally yes the visuals should be the same but there are differences between a static image and an interactive editor.
For example the linked in/out have no Label in the editor but with a mouse over one see the label. What to do in the case of an image?
Either it ends with an interactive image or difference between the two. I would prefer to keep the image static but understandable.
I'll try that out, it might be confusing but we'll see!
Nothing wrong if choosen solution has some limits but still, it shouldn't add anything what actually doesn't exist. It is just misleading.
Misleading is perhaps too much since the triangles only show the flow of data. It's a clarification of a feature. It might be confusing but so is having just rectangles.
Perhaps the best option would be to make the image interactive (limited to zoom and highlighting perhaps) but that opens the mobile v. Desktop can of worms.
