Mastering Shiny

Chapter 13. Why Reactivity?

Introduction

The initial impression of Shiny is often that it’s “magic.” Magic is great when you get started because you can make simple apps very, very quickly. But magic in software usually leads to disillusionment: without a solid mental model, it’s extremely difficult to predict how the software will act when you venture beyond the borders of its demos and examples. And when things don’t go the way you expect, debugging is almost impossible.

Fortunately, Shiny is “good” magic. As Tom Dale said of his Ember.js JavaScript framework: “We do a lot of magic, but it’s good magic, which means it decomposes into sane primitives.”¹ This is the quality that the Shiny team aspires to for Shiny, especially when it comes to reactive programming. When you peel back the layers of reactive programming, you won’t find a pile of heuristics, special cases, and hacks; instead you’ll find a clever but ultimately fairly straightforward mechanism. Once you’ve formed an accurate mental model of reactivity, you’ll see that there’s nothing up Shiny’s sleeves: the magic comes from simple concepts combined in consistent ways.

In this chapter, we’ll motivate reactive programming by trying to do without it and then give a brief history of reactivity as it pertains to Shiny.

Why Do We Need Reactive Programming?

Reactive programming is a style of programming that focuses on values that change over time and calculations and actions that depend ...