improve `Zattrs` show method

[HelenaLC]

• .zattrs are read using jsonlite::fromJSON, and are represented as a Zattrs object for handling, validity checks etc.
• Zattrs in turn are currently display as a nested, partially collapsed list that is pretty ugly (see example below)
• alternatives might be to either figure out an automated, prettified list view; or defining a custom show method that is restricted to the most relevant information (in any case, asS3() would allow viewing list content as is)

> x <- file.path("extdata", "blobs.zarr")
> x <- system.file(x, package="SpatialData")
> x <- readSpatialData(x, tables=FALSE)
> meta(point(x))
An object of class "Zattrs"
[[1]]
[1] "x" "y"

[[2]]
    input.axes input.name  output.axes output.name     type
1 c("x", "....         xy c("x", "....      global identity

[[3]]
[1] "ngff:points"

[[4]]
[[4]]$feature_key
[1] "genes"

[[4]]$instance_key
[1] "instance_id"

[[4]]$version
[1] "0.1"

[Artur-man]

I once did a recursive as.list call to the meta and it worked, I will try again ...

[HelenaLC]

Not sure an iterative as.list() call wouldn't just make it worse, by only lengthening what's printed to the console... unless we wrap that with a more sophisticated list display. Vince mentioned list-viewer something something- I forget. Or we "don't care" and customize it to what we deem most relevant, e.g., channels and transformations. Anyone can always call as.list() to kill whatever show-method we got, if they like. Even the fact that these are directly accessible to the user is debatable, I guess.

[Artur-man]

https://stackoverflow.com/questions/32618369/is-there-a-way-to-view-a-list

library(lobstr)

my_list <- 
  list(
    "hello",
    list(
      c("some", "words", "here"),
      list(c(1:4), c(11:14)
      )
    ),
    list(
      list(
        list(10)
      )
    )
  )

tree(my_list)
#> <list>
#> ├─"hello"
#> ├─<list>
#> │ ├─<chr [3]>"some", "words", "here"
#> │ └─<list>
#> │   ├─<int [4]>1, 2, 3, 4
#> │   └─<int [4]>11, 12, 13, 14
#> └─<list>
#>   └─<list>
#>     └─<list>
#>       └─10

We can independently implement it in the Zattrs() if you want

[HelenaLC]

A cool! Maybe this is what Vince meant. What's it look like for some SpatialData element? Eg blobs_labels has a bit more than average content. Or the multi-channel one?

[Artur-man]

just a sec ...

[Artur-man]

It actually doesnt look bad ...

> tree(x@images$blobs_image@meta)
S4<Zattrs/list/vector/list_OR_List/NULL_OR_list/AssayData/vector_OR_factor/vector_OR_Vector>
├─multiscales: S3<data.frame>
│ ├─axes: <list>
│ │ └─S3<data.frame>
│ │   ├─name<chr [3]>: "c", "y", "x"
│ │   └─type<chr [3]>: "channel", "space", "space"
│ ├─coordinateTransformations: <list>
│ │ └─S3<data.frame>
│ │   ├─input: S3<data.frame>
│ │   │ ├─axes: <list>
│ │   │ │ └─S3<data.frame>
│ │   │ │   ├─name<chr [3]>: "c", "y", "x"
│ │   │ │   ├─type<chr [3]>: "channel", "space", "space"
│ │   │ │   └─unit<chr [3]>: "NA", "unit", "unit"
│ │   │ └─name: "cyx"
│ │   ├─output: S3<data.frame>
│ │   │ ├─axes: <list>
│ │   │ │ └─S3<data.frame>
│ │   │ │   ├─name<chr [3]>: "c", "y", "x"
│ │   │ │   ├─type<chr [3]>: "channel", "space", "space"
│ │   │ │   └─unit<chr [3]>: "NA", "unit", "unit"
│ │   │ └─name: "global"
│ │   └─type: "identity"
│ ├─datasets: <list>
│ │ └─S3<data.frame>
│ │   ├─coordinateTransformations: <list>
│ │   │ └─S3<data.frame>
│ │   │   ├─scale: <list>
│ │   │   │ └─<dbl [3]>1, 1, 1
│ │   │   └─type: "scale"
│ │   └─path: "0"
│ ├─metadata: S3<data.frame>
│ │ └─omero: S3<data.frame>
│ │   └─channels: <list>
│ │     └─S3<data.frame>
│ │       └─label<int [3]>: 0, 1, 2
│ ├─name: "/images/blobs_image"
│ └─version: "0.4"
├─omero: <list>
│ └─channels: S3<data.frame>
│   └─label<int [3]>: 0, 1, 2
└─spatialdata_attrs: <list>
  └─version: "0.1"

[HelenaLC]

Ha. Define "bad". This wouldn't fit in my standard panel layout for sure, and I don't find the object type information all that relevant in this context. - For current purposes (aka convincing ppl this is "sexy" and has a future), I'd be in favor of a custom method that shows what we have accessors for, i.e., deemed essential (axes, channels, coordinate transformation names/types etc.) I'm not liking the repetitiveness of the .zattrs, just by design. Just my opinion & happy to be disagreed with!

In my mind, I'm picturing sth SCE-style, as always... where every row is an entry with an accessor (axes(), channels(), coordNames() etc.) - so that "you see what you get".

[vjcitn]

try listviewer package jsonedit gives collapsible tree

[Artur-man]

Will populate show method further.

> meta(image(x))
class: Zattrs
axes(3): c y x
channels(3): 0 1 2

[LucaMarconato]

Ha. Define "bad". This wouldn't fit in my standard panel layout for sure, and I don't find the object type information all that relevant in this context. - For current purposes (aka convincing ppl this is "sexy" and has a future), I'd be in favor of a custom method that shows what we have accessors for, i.e., deemed essential (axes, channels, coordinate transformation names/types etc.) I'm not liking the repetitiveness of the .zattrs, just by design. Just my opinion & happy to be disagreed with!

In my mind, I'm picturing sth SCE-style, as always... where every row is an entry with an accessor (axes(), channels(), coordNames() etc.) - so that "you see what you get".

I agree with this. Precisely, I'd let the user see the full tree if the ask for such detailed information, but as a default I would show a prettified view of the most important points.

For instance

│ │   │ └─S3<data.frame>
│ │   │   ├─scale: <list>
│ │   │   │ └─<dbl [3]>1, 1, 1
│ │   │   └─type: "scale"

can be shown in a single line. Same for other types of metadata.