filter_select() and friends should be able to respond to crosstalk events about crosstalk HOT 6 OPEN

Wanted to bump this, is there currently a way to get a select_filter's choices to depend on another select_filter? in pseudocode

dessert_df = data.frame(
  rating = c(1,2,3,4),
  dessert_type = c("Candy", "Pie", "Candy", "Pie"),
  dessert_subtype = c("KitKat", "Lemon", "Snickerdoodle", "Pecan")
)
dessert_sd = SharedData$new(dessert_df)

dessert_types_ft = filter_select("dessert_type", "Dessert Type",
    dessert_sd, ~dessert_type)
dessert_subtypes_ft = filter_select("dessert_subtypes", "Dessert Subtypes",
    dessert_sd, ~dessert_subtype)

Where dessert_subtypes_ft's choices will depend on the dessert_type_ft choice?

Edit: I'd like to not have to have shiny as a dependency

from crosstalk.

Sorry, I don't understand. The two events in Crosstalk are that someone made a selection or that someone changed a filterhandle. Which of those events do you mean by "updating of items"? Neither of those seem to me like they'd affect a filter_select, as it isn't affected by selection nor by other filterhandles.

from crosstalk.

The two events in Crosstalk are that someone made a selection or that someone changed a filterhandle.

I get that, but it seems as though you are tying a "selection" events to direct manipulation of graphical objects, and "filter" to indirect manipulation. I think of it more generally -- either event should be able to be triggered via direct or indirect manipulation. IMO, this is especially important for selection events (if you're curious why, see this short explanation), which is why I implemented a selectize widget that responds to a crosstalk selection event (i.e., the selectize items are updated upon a selection event). Notice the bidirectional communication between the widget and the plot in this gif:

Which of those events do you mean by "updating of items"?

Both...for the reasons I layout above, I would like to see crosstalk widgets update their value when a relevant event is triggered (regardless of how they are triggered). I would also like to see crosstalk widgets that can trigger selection events (e.g., select_checkbox(), which would be just like filter_checkbox(), except triggers a selection event, rather than a filter event).

PS. this is how I view the difference between selection and filter:

• Filter: completely remove the "non-selected" data, and update the layout accordingly.
• Selection: dim the "non-selected" data, keeping the layout fixed.

from crosstalk.

I agree that direct vs. indirect is orthogonal to filter and selection. Your P.S. captures the most important distinctions between filter and selection, we're in agreement about that.

But one other important aspect is that there is only a single "selected" state for a given group, and whoever mutates it last completely overrides any previous values; while for filters, each widget or whatever has its own handle that has its own independent state (set of keys), and the group's overall filter state is the intersection of all of those sets.

Therefore, it totally makes sense that you created a selectize widget that both sets and responds to the selection state; whenever a selection event occurs in another widget, just override your current state to reflect the new state. But doing so with a filter control is a different proposition; when another filter component has changed its contribution to the overall filter state, what does that mean for your state?

There is at least one good answer I know of to that hypothetical question, which is, your state doesn't change but you filter down your visible choices to the intersection of every other filter handle's set except your own. But I don't think you can implement this with Crosstalk today, and I made that decision consciously.

I get that having filter controls that respond to other filter controls is a reasonable and quite desirable feature, e.g. pretty much every dc.js/crossfilter demo. I punted on this scenario for v1 of crosstalk--not because the crosstalk part of it would be difficult to implement, but because the burden on widget developers to support this correctly seemed unreasonably high (unless you started writing your widget from scratch with this kind of interconnected filtering in mind, as was the case for dc.js).

from crosstalk.

Ah, I see, I didn't know that about the automatic filter state resolution, which makes sense. That now makes me wonder: wouldn't it make sense to update a filter's choices based on the current state?

Also, I agree that a filter's current value shouldn't react to whatever another filter is doing (essentially because of the AND logic -- for details, see below).

Anyway, I still think there should be some sort way to set a filter's value at print time #16 (comment)

from crosstalk.

crosstalk::filter_checkbox leaflet is not working when I add a second addCircles to leaflet. The filter stops working. See minimal example below. I apologize in advance is this question is not according to form, I am new to rstudio and this is my first questions.

title: "crosstalk::filter_checkbox leaflet"
output: html_document
date: "2022-12-14"

knitr::opts_chunk$set(warning = FALSE, message = FALSE) 

library(leaflet)
library(crosstalk)

tstd = data.frame(lng=-116.3013+rnorm(10)/100,lat=33.1005+rnorm(10)/100,
           Level1=c("L","L","L","L","L","H","H","H","H","H"))

sd_tstd <- SharedData$new(tstd)

crosstalk::filter_checkbox("Level1", "Level One", sd_tstd, ~Level1, inline = T)

leaflet(sd_tstd) %>% addTiles() %>% setView(-116.3013, 33.1005, zoom=13) %>% 
  addCircles(lng=~lng, lat=~lat, radius=99, stroke=T , weight=1, fill="Grey",  color="black", opacity=1, group = "No Fill" ) %>%   addCircles(lng=~lng, lat=~lat, radius=99, stroke=T , weight=1, fill="Blue",  color="black", opacity=1, group = "With Fill" ) 

from crosstalk.