Implement generic view()

[krlmlr]

view.default <- function(x) {
  if (interactive()) {
    View(x)
  }
  invisible(x)
}

I wonder if this function should do anything useful in non-interactive mode.

[krlmlr]

If I call utils::View() from tibble, I get the "old" data viewer, even in RStudio. @hadley: Please advise.

[hadley]

As opposed to the RStudio one, you mean?

[krlmlr]

Yes.

[hadley]

From @kevinushey: we can get the RStudio version with get("View", envir = as.environment("package:utils")). In the long-run, there will be an exported rstudioapi function

[krlmlr]

Maybe rstudioapi should just implement view()? I still wonder if that generic should live even in a lower-level package, maybe rlang?

[krlmlr]

I'm convinced this should live in a separate package, I have drafted https://github.com/krlmlr/tidyview.

I understood the following requirements:

• A function that acts like utils::View()
  • The title for the viewer is autodetected
• It is easy to override the default behavior

I also added my own:

• It is easy to turn off an override
• It is easy to add custom behavior: for instance, an sf object could be viewed with a widget capable of displaying spatial data
  • view() isn't tied to a particular type of object, e.g. non-rectangular data should also be viewable

The "simple" solution in #428 has a few deficiencies which led to implementing tidyview:

• Getting the label for an expression is difficult for S3 methods: enquo and S3 methods r-lib/rlang#553

• I don't like overriding by implementing a generic

  • can't easily turn off the override
  • override needs to reimplement autodetection of title

As for the other requirements, we should talk about how important they are.

[rpruim]

I think this is heading in a good direction, and I installed tidyview to take a quick look at the current implementation. A few questions to think about:

• When you talk about turning off an override, do you mean doing that for individual viewers (say just for sf objects) or just returning to the default state and starting fresh?
• Should it be easy to turn on a set of custom viewers? To save the current set? (like with options())
• If you add several custom viewers (perhaps for some special objects, or perhaps to get non-standard behavior), should it be easy to toggle back and forth between the default and this set of customizations or will will returning to the default essentially throw away the current set of customizations?

I can envision two ways viewer customization might get used:

• Micro: Viewers get created for new types of objects (as in your sf example) or to modify how one particular type of object is viewed.
• Macro: A user might have several sets of viewers (each set of viewers handling the same (large?) collection of object types) that reflect different styles/verbosity/etc. and choose among them depending on the situation.

(Note: I'm not quite sure whether what I am thinking of when I say "viewer" is the same as what you mean by an "override". I'm using viewer much like the factories in your current tidyview, but not bound to a particular implementation.)

[krlmlr]

Thanks for your feedback.

Good point about starting afresh, that's relatively easy to add.

I'd say recording/recreating state is out of scope (and difficult too), users should rerun code that sets up their preferred viewers.

Eventually, the default view() could even be a no-op, and IDEs or users need to actively set up their viewers.

Would it be too bad to rename view_handler to viewer in the code, so that view() calls a viewer?

[rpruim]

I like the shortened names. In fact, in my quick test, I renamed things. (The details of my viewers are not really important -- I just needed something to give it a test drive.)

vector_viewer <- function(x) {
  if (! is.vector(x)) return (NULL)
  
  function(x, title) {
    if (interactive()) {
      get("View", envir = as.environment("package:utils"))(x, title)
    } else {
      message(title, " (", abbreviate(class(x)[1], 3), " [1:", length(x), "]): ", 
              paste(head(x, 6), collapse = ", "), if (length(x) > 6) ", ..." else "", sep = "")
    }
  }
}

data_frame_viewer <- function(x) {
  if (! inherits(x, "data.frame")) return (NULL)
  
  function(x, title) {
    if (interactive()) {
      get("View", envir = as.environment("package:utils"))(x, title)
    } else {
      message(title)
      message(class(x)[1], " ", nrow(x), " x ", ncol(x))
      message(paste(capture.output(tibble::as_tibble(x)), collapse = "\n"))
    }
  }
}

register_viewer <- function(...) {
  dots <- list(...)
  lapply(unlist(dots), register_view_handler_factory)
}

# register the viewers all at once
register_viewer(list(vector_viewer, data_frame_viewer))
# or this way
register_viewer(vector_viewer, data_frame_viewer)

I thought it would be nice if register_viewer() could take either multiple viewers or a list of viewers as input. That way a suite of viewers could be registered all at once, much like a theme in ggplot2.

I also played around a bit with cat() vs message() to produce output. Is one of these clearly the right/wrong way to go?