Revisting the SuperZip example: what would you change?

shiny
1

The Super Zip Explorer Shiny app was what inspired me to tackle the Shiny learning curve. It's such an elegant illustration of the power and potential of Shiny, and I encourage anyone who hasn't seen it to spend some time using the app and browsing the code.

I have modeled many of my map + graph projects after this app, to varying degrees of success. Like many Shiny developers, I found that my apps became a chore to manage and debug because of the complexity of the reactive dependencies. I've also found it necessary to muck around in JavaScript from time to time, which is fine but also serves as a constant reminder that I do not know what I'm doing.

As I stumbled through the development of my apps, I found some helpful resources along the way that inform the pattern of my apps:

  • @jcheng's presentation at the 2017 Shiny Developers conference helped bring a lot of clarity to how reactive expressions ought to be used
  • the modules pattern which clarifies the intended method for reducing reactive complexity
  • the crosstalk package which leverages R and JavaScript to make it easier for htmlwidgets to access a shared data object

I'm guessing there are other helpful packages and methods that would allow me to make better map + graph apps, so I hope that folks can use this topic to share them.

So here's my question: if you were to redesign the SuperZip example today, what changes would you make and why?

2 Likes
2

The reactivity aspects of SuperZip are still mostly best practices, except that req() and observeEvent/eventReactive didn't exist at the time. I might use modules, though there's really not very much code anyway.

I know a little more about geospatial these days, maybe I'd make an interpolated raster instead of points? That's at the edge of my gis abilities and near the edge of what people have done with leaflet + Shiny, I think. Maybe a good project for the next round of example apps, thanks for the inspiration!

2 Likes