ggplot2 layer explorer shiny app (new and improved!)

[yjunechoe]

Thanks to lots of comments from Teun, a new and improved version of the layer explorer shiny app! https://yjunechoe.github.io/ggplot2-layer-explorer (link to code)

Hoping to get one last round of internal comments here before release the app out into the wild 😁

ggplot2.layer.explorer.demo.mp4

Still on the development wishlist:

• Support for non-Layer ggproto methods
• A broader FAQ/About page on ggplot internals, the app tech stack, link to code, etc.
• Better error messages and tracebacks

[yjunechoe]

@teunbrand

I realized the reason for my Layer$compute_geom_2() fumble! shinylive uses the CRAN version (3.5.2) where the change hadn't hit yet. When I run locally using dev ggplot, I can indeed inspect the guide data with cond = 1 (versus the layer data with cond = layer_is(1) which evaluates to cond = 2 for this example)

And on the $constructor thing... I narrowed it down! I think I have a good idea of the minimal reprex and fix -- will file an issue :)

[EvaMaeRey]

Thanks for the demo yesterday June! That was fun.

I think I could contribute some real-life debugging questions - I know there are some scattered throughout these discussions - I think when I try to do layer-wise computation, where some summarize without grouping by PANEL deletes the PANEL col, and nothing is drawn. 🤦‍♀️ @teunbrand has just jumped in in those cases, and it all makes sense after the fact. I will share on how it goes!

[teunbrand]

I think this is exactly the kind of granularity that is hard to consolidate in the app, or am I mistaken?

[EvaMaeRey]

I think this is exactly the kind of granularity that is hard to consolidate in the app, or am I mistaken?

I guess that's what I'm wondering.

The following represents naive code, where second layer data is wiped out, so no global means point displayed in all panels which is what I was after (not sure why), and needed an assist. I wonder if trace/app could have helped. Haven't tried yet!

library(tidyverse)

compute_layer_mean <- function(data, ...){
  
  data %>% 
    summarise(x = mean(x),
              y = mean(y))
  
}

########  layer wise computation via compute_layer ####
StatMeanlayer <- ggproto(`_class` = "StatMeanlayer",
                         `_inherit` = Stat,
                         compute_layer = compute_layer_mean)

# expect a point in each facet that computes the mean for the entire layer. 
ggplot(cars) + 
  aes(speed, dist) + 
  geom_point(size = .15) +
  layer(geom = "point", 
        stat = StatMeanlayer, 
        position = "identity") + 
  aes(color = speed > 15) +
  facet_wrap(facets = vars(speed > 15))

A fix was PANEL preserving compute - if awkward:

compute_layer_mean <- function(data, ...){
  
  data %>% 
    distinct(PANEL) ->
  panel_df
  
  data %>% 
    summarise(x = mean(x),
              y = mean(y)) %>% 
    crossing(panel_df)
      
  
}

[yjunechoe]

kind of granularity that is hard to consolidate in the app

Yeah, I think so. Especially because the "no PANEL column = no drawing anything" behavior is implemented by a Layout method, which is not showcased as part of the app.

I think in general the app would be limited in usefulness for a developer using the app to debug a custom ggproto method because so many things can go wrong. In such cases maybe just using {ggtrace} with its full flexibility (not confined to the steps on the sidebar) would be more helpful.

"Forgot to preserve PANEL column" is a really interesting problem, though - I'm sure others have encountered it and it'll be worthwhile trying to guard against it. But for the life of me I cannot imagine a good way to impart that lesson to a learner other than just repeating this fact back to them and have them bang their heads against the wall until they get it (which is how I learned not to make this specific error). If this is indeed a common issue for developers, maybe it'd help to have a warning where an unexpected behavior would be produced. Stuck on this problem myself!

A fix was PANEL preserving compute - if awkward:

IMO the awkwardness comes more from using dplyr and reading/writing a code with lots of indirection. In base R, doing the same thing doesn't look too bad!

compute_layer_mean <- function(data, ...){
  
  data.frame(
    x = mean(data$x),
    y = mean(data$y),
    PANEL = unique(data$PANEL)
  )
  
}

[EvaMaeRey]

That does look nicer! I guess crossing might advantage of working for non-length one computations (which do not come to mind - but theoretically). I can't remember the base R crossing function. expand?

"Forgot to preserve PANEL column" is a really interesting problem, though - I'm sure others have encountered it and it'll be worthwhile trying to guard against it. But for the life of me I cannot imagine a good way to impart that lesson to a learner other than just repeating this fact back to them and have them bang their heads against the wall until they get it (which is how I learned not to make this specific error).

😆

I think in general the app would be limited in usefulness for a developer using the app to debug a custom ggproto method because so many things can go wrong. In such cases maybe just using {ggtrace} with its full flexibility (not confined to the steps on the sidebar) would be more helpful.

Curious what it might look like in this specific case at some point in the future.

[yjunechoe]

New additions from last meeting's comments:

Displays current layer (ex: "geom_smooth()") and also adds a button:

The button, when clicked, opens a pop-up showing more info about the selected Layer:

[teunbrand]

Cool, this makes it also very clear what methods are from the child and the parent! This is sometimes hard to grasp when dealing with these classes

[yjunechoe]

Yeah!! And now that I've implemented this as a separate modal, if there's any other interesting layer-level info that could get shoved in here, please lmk :)