Reactive Web Dashboards with Shiny Transcripts
Chapter: Reactivity
Lecture: Dynamic reactivity
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
In the previous exercise, we went through this application and looked at how the application minimally re-renders in response to a given change.
0:11
And we ended up with this execution graph for that application. One thing that you might think is,
0:17
Why did we go through all this work of discovering these dependencies each time when they don't change?
0:22
So for this application, all the dependencies are going to be the same, regardless of what the user does for that element.
0:29
But these graphs actually are a lot more powerful, and they can support what's called dynamic execution. Let's take a look at an application like that.
0:38
This is a very simple application. It just echoes the value of a slider. But we have this second input here, which is a radio button input,
0:48
which tells Shiny which slider to listen to. So here, when it's selected slider 1, slider 1 changes the value of the text, and slider 2 doesn't.
0:58
But if I change the button to slider 2, now slider 1 doesn't do anything, and slider 2 is what powers the value of that text.
1:07
When you look at the code that's generating the output, it's a very simple conditional.
1:12
It's just the same thing that you would write if you were writing Python code outside of a web application.
1:18
We have this input choice conditional, and then if that's slider 1, I'm going to return the text value that refers to slider 1.
1:27
And if it's not, I'm going to return the value that refers to slider 2. Again, no callbacks here, no state management, just a very simple conditional.
1:36
But Shiny's kind of doing the right thing, and figuring out that it doesn't need to invalidate this,
1:42
it doesn't need to redraw this text if the irrelevant slider is fired. Again, when Shiny starts up, it just knows that there's three things.
1:51
So we have the buttons, the button value, and then the two sliders. Three inputs and one output, the text output.
1:58
When the application opens, just like before, we try to draw the output. So we draw the text output, and the first thing it needs is the button value.
2:06
So it goes and gets the button value, and when it first starts out, the button value is slider 1.
2:11
And with that conditional, we go and use the value of slider 1.
2:15
And we end up with this graph. There's a dependency on buttons, a dependency on slider 1, but importantly, not a dependency on slider 2.
2:22
Because in the early return, this output never asked for the value of input slider 2, so there's no dependency there.
2:30
What that means is that when slider 2 changes, nothing happens. So slider 2 changed, but we didn't need to re-invalidate the text output,
2:40
because there wasn't a dependency between slider 2 and the text output. It's worth taking a minute to reflect on why this is correct.
2:47
So whenever you have an early return on a function, what you're effectively saying is
2:52
that anything that happens outside of that, or after that early return, doesn't matter.
2:57
So since we didn't use the value of slider 2 last time we calculated the text input,
3:02
it could be any value, and it wouldn't change the outcome of that function. It could be 1, 2, banana. It really doesn't matter, right?
3:09
Because we were able to calculate the value of text output without ever reaching for that value in the first place.
3:16
And if that's the case, that means that if a user changes that value to anything, it shouldn't affect the output of text output.
3:25
If slider 1 changes, we do the same thing that we did before. Invalidate text output, go get the buttons, still says slider 1,
3:32
so we go and get slider 1, and we're back. But if the button changes, the same invalidation happens, but we end up with a different graph.
3:41
So when we calculate the graph this time, button says ""go get slider 2, and so we go get slider 2, and now slider 1 is the orphan input
3:49
that doesn't affect any of the outputs. And just like that, we have this different graph.
3:54
Again, for a very simple graph like this, the one that's easy to see in a microcosm, this doesn't matter that much.
4:02
It could fire again if the irrelevant slider changed. But you could imagine this being a bigger application,
4:08
or something with more complicated or time-consuming functions, and having this kind of ability to avoid re-execution
4:16
is going to really make your application faster and more accurate.