The book "Mastering Shiny" has a section on hierarchical select boxes, for the purpose of drilling down into a dataset across multiple categories. This is described here.
The structure here reproduces that strategy, but with a larger dataset, with both more rows and more columns than shown in the example.
In addition, logging is added to each reactive context, to identify when and how often each item runs.
With larger data, this strategy is fairly slow.
On launch, the app needs to set a value for colA, and in so doing, discover what values are valid for colB. The order of events ought to be like so:
Initialize value for colA.
Find valid values for colB given colA; set value for selectInput.
Find valid values for colC given colB; set value for selectInput.
Find valid values for colD given colC; set value for selectInput.
Find valid values for colE given colD; set value for selectInput.
End.
But instead, the output looks like this on startup:
DEBUG [2022-10-12 00:02:59] Getting unique colB to set selectInput choices
DEBUG [2022-10-12 00:02:59] Getting unique colC to set selectInput choices
DEBUG [2022-10-12 00:02:59] Getting unique colD to set selectInput choices
DEBUG [2022-10-12 00:02:59] Getting unique colE to set selectInput choices
DEBUG [2022-10-12 00:02:59] Getting unique colC to set selectInput choices
DEBUG [2022-10-12 00:02:59] Getting unique colD to set selectInput choices
DEBUG [2022-10-12 00:03:00] Getting unique colE to set selectInput choices
DEBUG [2022-10-12 00:03:00] Getting unique colD to set selectInput choices
DEBUG [2022-10-12 00:03:00] Getting unique colE to set selectInput choices
DEBUG [2022-10-12 00:03:00] Getting unique colE to set selectInput choices
Each input triggers refresh of the inputs below it in the hierarchy, such that colE (which is last in the hierarchy) ends up getting refreshed four times (and the data are filtered on the value in colD 4 times).
Is there a better scheme that minimizes how many inputs need to be refreshed in the hierarchy?
I've attempted instead to use a combination of renderUI and uiOutput, and on
each renderUI instance, setting bindEvent to the category above it in the
hierarchy (to be displayed in app2.R when ready). This solution is faster, but
has its own problems; if a value is valid for, say colB, when colA is changed,
anything dependent on colB further down the hierarchy will not refresh and we
end up with potentially invalid levels for C, D, and E.
The project dependencies are defined by renv; use renv::restore() to install
all relevant packages.
The app is contained in the app1.R file; source this file to run. app1.R
itself will source the script to create the data before launching the shiny
app. A file data.db will be generated, about 600MB in size.