1. Reactive variables
You may have noticed that in the last few exercises,
2. Code duplication
the code to filter the data, which is 11 lines long, was duplicated three times.
It was used initially in the rendertable function to show it in a table, then it was copied into the renderplot function, and finally it was also duplicated into the download handler code.
3. Reactive variables reduce code duplication
One potential problem with duplicating chunks of code is that all copies of the code have to be constantly maintained.
For example, if any new inputs are added to the app and the filtering code becomes longer, you need to remember to update the code in all three places.
Similarly, if any bugs are found and you need to update the code, again it would have to happen in all places.
Over time, it's easy to accidentally let the multiple code chunks become different by not updating all of them, and this can then introduce errors into your app.
In Shiny, when the duplicated code contains reactive values, then creating a reactive variable is a good solution.
4. Reactive variables
To illustrate how reactive variables can be used to resolve code duplication, let's suppose this data filtering code inside this renderTable function is duplicated in a few places.
To turn it into a reactive variable, first we create a variable, in this case we'll call it my-underscore-data, and assign the `reactive()` function to it.
We then copy the duplicated piece of code into the reactive function.
Now my-underscore-data is a reactive variable that can be used inside the renderTable function or anywhere else that previously duplicated the code. Just remember that when accessing a reactive variable, you need to add parentheses after the variable name.
5. Reactive variables caching
Other than helping to reduce code duplication, using reactive variables has a couple more important benefits.
Reactive variables do something called **caching**—they cache their value. This means reactive variables store their value after running the first time, and they do not run their code again unless one of their dependencies was modified. This can be especially useful when a reactive variable takes a long time to compute.
6. Reactive variables caching
Consider this example: suppose there's a model fitting function that takes five seconds to run and it uses, or depends on, one of the app's input values. In this server code, both the table and plot render functions are using the result of the fit.
Since the fit function is called twice, this code takes 10 seconds to run.
Now suppose instead that a reactive variable `x` is created to contain the duplicated model fitting code.
Now the two render functions can use this reactive variable.
Even though x is called twice, it only runs the first time, because the second time it's called it remembers its value and doesn't run the model fitting again. This means that this code runs in 5 seconds, which is a significant speed boost.
7. Reactive variables are lazy
Another useful property of reactive variables is that they are **lazy**. This means that a reactive variable only gets run when its value is needed.
To see how this can be useful, consider this code. Again, we have a reactive variable x that takes a long time to calculate and depends on an input. This reactive variable is used in a download handler, which means that every time the user requests to download the file, x will be called.
The benefit of laziness is that thanks to it, x does not get recalculated every time input-dollar-sign-num gets updated - that would be very slow and a waste of time. x is only recalculated when the input changes *and* its value is needed, meaning only after the user clicks on the download button.
8. Let's practice!
Now let's test your understanding of reactives.