Feature request: diff drill-down

[billyjanitsch]

In the diff above, one can toggle the visibility of the state around the diffed portion (router) but can't peek into the content of the diff itself (i.e. the object can't be expanded).

This sort of diff drill down would be very useful, e.g. when inserting entities. Any chance of adding it?

[alexkuz]

I don't have plans for that currently. Maybe we could render two json trees there, but I'm not sure it would work well. Or maybe render it in a separate panel, when before- or after-value is clicked. That would be also useful for long strings, by the way.

[axelson]

Can we at least get a tooltip that will show the entire diff/new string? That would make the diff SO much more useful.

[vdh]

I think the length-based truncation inside the JS should be removed altogether, and instead replaced with a CSS solution with text-overflow: ellipsis and flexbox, which would let the browser handle truncation within the available space.

Of course, being able to drill down into objects/arrays inside diffs would be a lot better than stringification, but even innocent bystanders like an ISO8601 string get mangled by the truncation:

value(pin):'2016-07-29T14:…0:00' => '2016-07-29T14:…0:00'

[alexkuz]

@vdh in general, I prefer truncation in middle, because the end of string can be meaningful. In this case though it may be not so relevant. Or we could just increase the limit, if ISO8601 string is the most critical usecase.

[vdh]

@alexkuz Here's an example I threw together in JSFiddle for dynamic truncation based on container width: https://jsfiddle.net/vdh/xhhsep47/

Apart from generating the HTML with JS, the "truncate-end" examples are pure CSS, and the "truncate-middle" examples just use the JS to split the string in half.

The "truncate-middle" examples unfortunately have a visual bug with the right-side characters getting clipped vertically, but unless I'm mistaken there's no pure CSS way to crop by character. I'm sure this limitation could be overcome by some very crafty dynamic JS truncation with an window resize handler, but I didn't want to dive into dynamic JS text handling right now. But hopefully these examples show how much better dynamic truncation is over static length-based truncation.

[zalmoxisus]

@vdh, besides texts, there could be functions, arrays and objects, where middle truncation is better. Otherwise, the example in this issue will look like null => {pathname:'/',s... instead of null => {pathname:'/',s...:''}}.

Also it's like Mac's finder show text and Chrome console show objects and arrays (with truncation in the middle).

Dynamic truncation would be useful, but we should then move it to react-json-tree part.

[alexkuz]

The "truncate-middle" examples unfortunately have a visual bug with the right-side characters getting clipped vertically, but unless I'm mistaken there's no pure CSS way to crop by character.

yeah, that's why I'm not a fan of CSS solution. I think it's not so hard to write react component that will do it properly, though - weird that noone made it yet, actually :) (at least I can't find it right away)

[zalmoxisus]

@alexkuz, what if we'll not stringify and shrink diffs, but just show them as full tree? I guess it will be more helpful and also will avoid issues with circular references and special types that javascript-stringify has.

Something like here:

[alexkuz]

@zalmoxisus this can affect performance significantly (like adding a list with thousands of items). It should truncate huge arrays, objects and iterables, as react-json-tree does. Or at least has a reasonable limit for rendered string.

[zalmoxisus]

@alexkuz, I meant to show the objects / arrays with react-json-tree, and additionally we could truncate strings inside react-json-tree.

[zalmoxisus]

Ideally, react-json-tree should deal better with a list of thousands of items then javascript-stringify does, because we render only the list's structure first. If not, implementing smth like react-virtualized there would help.