Compare side by side, beyond diff.

[fischerdouglas]

I'm talking about the comparison feature at https://tikoci.github.io/restraml/

The suggestion is to have the option to compare side by side, in addition to the diff option.
Something very similar to the compare function in github, already doing the pre-collapse of the same sections between the versions.

--
Thanks again, and congratulations on the project!

P.S.: I hope you don't mind the multiple issues I opened.
I did it this way more fragmented because I think it's easier to link the commit and the issue.

[mobileskyfi]

Same story as #15 ...

I kinda think that converting the inspect.json to some RouterOS-like syntax then diffing that syntax. Perhaps taking liberties from standard syntax to deal with arg value description that change (these are ones that come from a =F1 so there is not a "syntax" for that...

Some format like as the "starting diff" I think be better:

/ip
  /address
      # Create a new item  
    add
      # Set comment for items 
    comment
      # Disable items 
    disable 
      # Change item properties
    set
        # Broadcast address 
      broadcast=(> "A.B.C.D    (IP address)")
        # Interface name  
      interface=(> "lo | ether1 | ether2 | ether3 | ether4 | ...")

Which really same as inspect.json used today in diffs already structures and knows about from /console/inspect request=syntax – just be different rendering. In text, so "normal" wen diff libraries work and allow side-by-side.

[mobileskyfi]

Did do a quick test here with Gemini LLM and site's code in docs/index.html - which is the entire code for the site.

Accidental, but "restraml" page uses "semantic HTML" and pure "vanilla" JavaScript event handlers (no frameworks, not even jQuery) - no doubt this is "easier" for an LLM than some complex React/etc site. So why I gave this a go with "AI", got mixed result... although it re-confirm that JSON diff is hard problem.

First try
It worked, but showed everything and takes a good minute to render. See
https://tikoci.github.io/restraml/sideview-g2.html

2nd try
Told Gemini that, it suggested it was a hard problem (something I knew ;)), but still didn't work.
https://tikoci.github.io/restraml/sideview-g2.html

Since I'm not sure JSON is best. That where I stopped.

Convo with Gemini to get above is here: https://g.co/gemini/share/11a3c2c9d1ff

Anyway, I still think rendering the raw diff data as RouterOS-like syntax in text – not JSON – is better approach to the "diff view".

Internally, the "stats" actually uses a different library/approach, which uses JSONPath (now RFC-9535) and deep-diff to "pivot" the inspect.json

const types = (new jsonpath.JSONPath()).query(ejson, `$..*[?(@._type)]._type`)
const stats = { arg: 0, cmd: 0, dir: 0 }
types.forEach(x => stats[x]++)

(above 3 lines generate the counts just below each version dropdown, the overall changed/added/removed comes from deep-diff further down in docs/index.html - which is what actually knows the changes in versions)

Any approach, I think, is "transform" each inspect.json into a RouterOS-like "config" — then finding some good text-based (not JSON-based) diff HTML/JS library to render the diff between pseudo RouterOS config.

Still going to mull on it. And, to borrow MikroTik phraseology, "no promises".

[mobileskyfi]

And perhaps more :export terse style "pseudo RouterOS", which each arg, cmd, dir/path get it's own line – this work better for text diff tools. Like:

/ip/
/ip/address/
/ip/address/add # Create a new item  
/ip/address/add interface=(> "lo | ether1 | ether2 | ether3 | ether4 | ...") # Interface name 
/ip/address/add broadcast=(> "A.B.C.D    (IP address)") # Broadcast address

...that form convey all data from inspect.json, which includes:

• "desc" becomes a comment
• "_type" becomes the (> "") which is valid routeros syntax, on a line
• "dir"/"path" only have slash at end
• "cmds" no slash at end

I think this allow better "inline" diff colors to see if some of the enum-like (aka what show in winbox dropdown for some attribute) things changed.