Cheers Carson,
Yeah, so that last example is exactly what I was aiming for.
And very interested to hear that it can be applied to the other html widgets, as well.
I will have investigate these and also keen to see the % speed increase this technique brings (with bigger data), as opposed to re-creating the whole chart each time a filter is clicked.
Basically, this question is a bit pre-emptive (I currently don't have an app requiring this performance boost)... but I'm imagining it might be best practice (if it isn't any more complicated to implement than the "normal" way).
I'm curious whether using the "runtime: shiny_prerendered" and "```{r, context="server"}" will have any unintended consequences to other components of the flex dashboard. Will do some investigating.
Basically, I'm interested in this optimisation sort of things because I've been burnt a bit before, with a Tableau dashboard that required three left-joins (and 30,000 rows became 500,000,000 rows). It had a couple seconds delay when using any filters (which was frustrating). So that's why I've converted to R's Flexdashboard, as you aren't restricted in reshaping datasources and, with techniques like this, can be very responsive.
So, thanks heaps for your response...
btw, hate to take up any more of your time but, if you are looking for another ggplot/Plotly/Flexdashboard challenge, I have another "legend in the sidebar" question over on Stack Overflow that might be another cakewalk for you...