label formula fails when using crosstalk

[kent37]

Labels can't be specified as formulas when the map data is a crosstalk SharedData. Simple example:

library(crosstalk)
library(leaflet)

shared_quakes <- SharedData$new(quakes[sample(nrow(quakes), 100),])
map = leaflet(shared_quakes,) %>% addTiles() %>% 
  addMarkers(label=~as.character(depth))

gives error

Error in UseMethod("metaData") : 
  no applicable method for 'metaData' applied to an object of class "c('SharedData', 'R6')"

The problem is a simple mis-spelling at line 2 of normalize-SharedData.R. metaData.sharedData should be metaData.SharedData.

[kent37]

There are two additional complications to this.

• The result of calling metaData.SharedData may itself need to be unpacked with another call to metaData, for example if the SharedData is wrapping a Spatial* object. This is easily fixed by adding another call to metaData. pointData.SharedData and polygonData.SharedData already do something similar for the same reason.
• The second issue is deeper and arises because the leaflet and crosstalk packages have different ways to extract data from an object. leaflet uses (and extends) metaData while crosstalk uses lazyeval::find_data. Since crosstalk is not aware of leaflet::metaData, it does not benefit from the definitions in leaflet.

Here is an example showing both problems:

library(crosstalk)
library(leaflet)
library(sp)

# Get a SpatialPointsDataFrame
data(meuse)
coordinates(meuse) <- ~x+y
proj4string(meuse) <- CRS("+init=epsg:28992")
meuse =  spTransform(meuse, CRS("+init=EPSG:4326"))
meuse_shared = SharedData$new(meuse)

# Fails because filter_select doesn't know how to get data from a SpatialPointsDataFrame
filter_select('landuse', 'Land Use', meuse_shared, ~landuse)
# Error: Do not know how to find data associated with `x`

# Fails because metaData.SharedData returns a SpatialPointsDataFrame, not a data.frame
leaflet(meuse_shared) %>% addTiles() %>% addMarkers(label=~landuse)
# Error in as.character(x) :
#  cannot coerce type 'closure' to vector of type 'character'

I think the solution to the second issue is for leaflet to use lazyeval::find_data instead of metaData. Ideally other Crosstalk-enabled packages would do the same, extending find_data as needed. leaflet does not export the generic metaData so this change should not affect clients.

I have patches for both of these, if the fixes sound right I'll make a pull request.

[jcheng5]

Sorry, I'm a little lost. Does crosstalk indirectly use lazyeval::find_data via lazyeval::f_eval? Because I don't see a reference to lazyeval::find_data in the crosstalk repo...?

[kent37]

Yes. lazyeval::f_eval and leaflet:::resolveFormula do roughly the same thing - evaluate a single-sided formula in the context of an object. Both have the problem of figuring out the "data" part of the object, and both solve this with generic functions - leaflet:::metaData and lazyeval::find_data. Because they use different generics, they don't interoperate well. The metaData overrides defined in leaflet are not available to lazyeval::f_eval. That leads to the problem with filter_select in my example.

Ultimately it would be helpful if package authors settled on one way to implement single-sided formula lookup. Probably lazyeval is the way to do that since it is full-featured and part of the tidyverse. Then it might become common for implementers of new data structures to implement find_data overrides for their data, so find_data.SharedData would be in crosstalk, find_data.Spatial* would be in sp, etc. For now, I think using find_data instead of metaData in leaflet is a good step.

[jcheng5]

That's fair. FWIW, I believe @hadley is actively working on replacing lazyeval with rlang, but I don't see rlang::find_data--it might be rlang::data_source.

[kent37]

Yes, rlang::data_source looks like the rlang version of lazyeval::find_data. It has different semantics so data implementers will have to overload both find_data and data_source to work well with formula clients :-(.

[hadley]

Or someone can just provide a .default method that dispatches to the other generic. We do this a decent amount in the dev version of dplyr in order to allow functions programmed against the previous interface to work.

[jcheng5]

@hadley If we dispatch leaflet::metaData.default to lazyeval::find_data, will that cause problems if we want to move to rlang::data_source in the future? Or will data_source.default dispatch to find_data?

[hadley]

I think you'd be better off doing the switch to rlang at the same time

[kent37]

@jcheng5 I think lazyeval::find_data.default would have to dispatch to leaflet::metaData. That way clients of find_data (like Crosstalk) will take advantage of the older support in metaData. For leaflet, though, it seems simpler to just switch over to find_data directly.

[jcheng5]

@kent37 I don't think lazyeval should take a dependency on leaflet, that seems pretty backwards. But I'm sure we can convince the sp/sf maintainers to implement find_data (or, better yet, data_source).

[kent37]

Ok. That is more than I am willing to do (to get find_data support into sp, etc. I have a project I'm trying to complete, I will look for another way to do it.

[kent37]

@jcheng5 how about just fixing the metaData.SharedData problem, that is a clear bug.