Cool! Would be interesting to work on some definitions regarding "flow differences" and then use your flow viewer to highlight those differences.
So you have or you have not thought about it?? 
That thought had not really crossed my mind yet, but I'll give it some thought 
Full disclosure: it was exactly what I was thinking when I started! Where else does one find long lines of json flow data ... 
Another day, another update. In explaining (or trying to) what link nodes do, I've added images to the viewer - only some of the core nodes. Why? The difference between a link-out node that passes data to a link-in node and a link-out node in return mode isn't apparent without the icon change. (btw its interesting to note that a link-call node reverses the usage of the link-in and link-out nodes!)
I also added path highlighting - makes it easier to explain how data flows through the flows. See the bottom of the explanation for the weird affect when link-call node is made with a node that has multiple output connections.
I hope I don't think of anything else to add to the viewer ...
2 Likes
Update on this, the code is now over at github but it continues to be maintained as a Node-RED flow over here.
I like playing around with the flow viewer in Node-RED but I can understand that github is perhaps a better code hoster, so now it's best of both worlds (ok, no there isn't an github to node-red update process - will be built with the first pull request).
Having found the magic sauce on making github do commits via API calls, I actually did what I wanted to do all the time! All the stuff for the flow is checked in and it's quite nice since github really works well with diffs on files.
Not sure if you realised that an entry in the flow library is actually a GIST on your GitHub account anyway. So you can actually maintain it there. No real need to keep another copy (unless you want to) 
Gist aren't real fun when multiple files are involved. Also revisions aren't really first-class citizens in the gist world. The entire source basis for the .js is stored @ github, hence it can't really be just a gist.
Ok for those still reading this I've finally gotten to where I actually wanted to be with this plugin - strangely!
Warning: This is all very beta an liable to change and breakage!!!
It all starts with the idea that git diff is completely useless for a flows.json file. Is there a visual way to compare flows? No because the editor can't do it and there is no standalone plugin to visualise flows. But part one is done with this plugin, part two is finding a replacement for git diff.
But first: how to access github? I did that the other day and now have an automatic (thanks to the brilliant cron-plus node) backup flow that pushes a backup of all my flows to github every 2 hours. (Learning: with the github REST API you can produce empty commits, you need to compare SHAs before committing.)
So now I only needed to access those commits and visualise them. That now happens with this flow and the frontend is at https://backup.openmindmap.org/
Don't be alarmed if it doesn't work, it's a small heroku server and will die with traffic. If it does work, don't be alarmed about the styling: there is none!
Select something like the first 6 or 7 commits and hit the compare button. The default flow tab shown is the one that created the backup.openmindmap.org server - most changes I made there in recent days so most interesting flow to compare.
The services allows the selection of the commits (only the last 15 are shown - randomly chosen limit) and after that, a flow tab can be selected that is compared across those commits (using the slider at the top).
Yes: this does not do any textual comparisons, if the contents of a node changed, then that is not visually apparent - this purely visual changes, i.e. node additions, movements, deletions and label changes ...
Where to from here? First that last issue - content changes made visual ...
I know but I find that if I'm programming visually then I want to compare visually - why does there need to be a paradigm shift from visual to tabular when doing comparisons? I don't have a better solution but I would like to find a better approach.
Also I find that comparison too confusing since x & y changes of nodes are also highlighted - do I really want to know whether the x & y values have changed, does that have a semantic meaning or is that some syntactic (or better said: visual) information? So the changes being shown aren't all relevant or rather have no meaning in my head - what does it mean that x & y differ? And that is extra information that I have to keep track of in my head ...
Hence I decided to experiment with a different approach.
Edit: Strictly speaking, yes it is visual but so are the diffs at github - anything on a screen is visual. I guess I mean visual in my mind and not colourful dots on my screen visual! So a visual table is a table in my mind, a visual flow is a flow in my mind.
Edit2: Where's the editor code for doing that diff? I assume it runs completely in the frontend and I would like to do something similar also in the browser.
1 Like
Ok thanks for that, I used generateDiff and parseNodes to create a new version of the comparison tool.
I think this example presents it a little better - green is new, purple is changed and black is deleted. Use the slider to blend the two versions. Use the selector to change the flow tab to be compared. Entries in that drop down are postfixed with [....] if nothing changed between versions.
Edit: Update, there is now a diff popup if you click on a purple nodes (i.e. the ones that changed). The diff table tries its best to highlight changes and differences. The postfix [....] has become a prefix - easier to see which flow tabs have changed. For those interested, there is table with visual-diff links at github for the repo hosting my flow changes.
2 Likes
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
