Bay area R users were lucky to have to have the annual useR! conference in their back yard this week. Stanford hosted this year's conference, which is the largest R meeting in the country featuring four days of workshops, keynotes, and presentations. The popularity of this event is evident not only by the more than 700 attendees, but also by the fact that these 700 were the lucky ones! Conference registration maxed out weeks before the registration deadline and many others had to be turned away.
I attended a half-day workshop on Effective Shiny Programming by Joe Cheng, the CTO of RStudio and creator of Shiny. If you haven't already heard of Shiny, this amazing package allows R users to turn their R scripts into an application complete with a GUI that can be either run locally or online. As one of the attendees aptly remarked during the Q&A session, Shiny has been a 'game changer' for the R community. I use Shiny to provide a GUI for certain functions in my R package T-LoCoH that analyzes animal movement.
In his presentation, Cheng described conceptually how reactive programming works in Shiny. Shiny's default behavior is to automatically re-run scripts any time the user changes an input value through something like a slider. This works fine for simple tasks, but can slow down an app visibly and unnecessarily if data crunching takes more than a millisecond. Reactive programming lets you control when things are updated in a Shiny app.
Cheng explained how and when to use the main two types of objects that control reactivity. 'Reactive' objects (e.g., created with reactive(), reactiveValue(), reactiveEvent()) return values, are cached, and lazy (only called when needed). 'Observers', on the other hand, are eager (run when programmed to, even if they're not necessary for example if an output is not visible), never cached, and don't return values. Unless we need to precisely control when something is run, Cheng cautioned, we should use reactive objects which gives Shiny the power to decide when a value needs to be updated (and Shiny is generally better at doing this than programmers, especially as an app evolves). Observers are often used to respond to 'events' such as a button click. For more info on reactive programming, see 'How to customize reactions' in RStudio's excellent Shiny tutorial.
Cheng also gave a preview of some new features in the next release of Shiny, which should be out later this summer. One of the most exciting new features is the ability to record the 'state' of a Shiny app within the URL (so for example you can restore the position of sliders and other inputs). There will also be improved security for making database connections, and a new function (req()) which will make it a lot easier to check if all the required inputs from the user have been entered.
In a future post, I'll discuss the use of Shiny as a web GIS tool, how techniques like reactive programming offer capabilities to create powerful and flexible web applications, and when you might want to use a Shiny application instead of a more packaged web GIS tool like ArcGIS Online or CartoDB.
Jun 30, 2016