Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chapter 14 Typos #464

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Chapter 14 Typos #464

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
02f6bf7
Remove repeated word
MikeJohnPage Apr 9, 2021
e3e915a
Update reactivity-graph.Rmd
MikeJohnPage Apr 9, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions reactivity-graph.Rmd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -200,7 +200,7 @@ The arrows coming out of a node are one-shot notifications that will fire the *n
Now that they've fired, they've fulfilled their purpose and we can erase them.

It's less obvious why we erase the arrows coming *in* to an invalidated node, even if the node they're coming from isn't invalidated.
While those arrows represent notifications that haven't fired, the invalidated node no longer cares about them: reactive consumers only care about notifications in order to invalidate themselves and that that has already happened.
While those arrows represent notifications that haven't fired, the invalidated node no longer cares about them: reactive consumers only care about notifications in order to invalidate themselves and that has already happened.

It may seem perverse that we put so much value on those relationships, and now we've thrown them away!
But this is a key part of Shiny's reactive programming model: though these particular arrows *were* important, they are now out of date.
Expand Down Expand Up @@ -271,8 +271,8 @@ The neat thing about this process is that Shiny has done the minimum amount of w

## Dynamism

In Section \@ref(removing-relationships), you learned that Shiny "forgets" the connections between reactive components that it spend so much effort recording.
This makes Shiny's reactive reactive dynamic, because it can change while your app runs.
In Section \@ref(removing-relationships), you learned that Shiny "forgets" the connections between reactive components that it spent so much effort recording.
This makes Shiny's reactivity dynamic, because it can change while your app runs.
This dynamism is so important that I want to reinforce it with a simple example:

```{r}
Expand Down