Open gordonwoodhull opened 6 years ago
@useless5771, one simple example: I want to add a dropdown to a cell with a map (rcleaflet, rstudio leaflet or just R plot of some sort).
The dropdown has a list of the cities that I have data for. I attach an R callback to the control that fetches the relevant data and updates the map.
For people who don't want to think about callbacks, we'll have a few standard actions like "run the rest of the cells in the notebook", "run cell 17", "run cells 3-7". See att/rcloud#2602.
The latter are slightly unreliable due to possible cell renumbering, but that's the price you pay for not liking to think about functions. The most direct and reliable is to specify inline or declared callback functions.
@useless5771, this was one of the things that came up when I reviewed the current functionality with @s-u.
Having on_submit
for a form works for some things, but it's also important to be able to respond to on_change
for a whole set of things, or just globally. The most common case will be "run the rest of the notebook (or run some function) when any of these controls change". I didn't poke too deep in the code, but I didn't see this in your examples so far.
We don't want to turn this into a whole reactive framework with a control flow graph like Shiny, but we do want to support some reactive use cases.
To this end, we want to allow callbacks on
param_set
After the data has been validated (on the R side, as now), the query string should be updated, and then the callback called. Let's use the same function signature for all three kinds of callbacks, even though some of the information will be redundant.
I.e. the callback function should have the signature
function(parameter_name, value) {... }