Lise Vaudor
janvier 2021
Dans sa version la plus simple, la chaîne de réactivité ressemble en fait à ceci :
C’est, pour le moment, le seul type de réaction que l’on a abordé.
Pour rappel, voici comment l’on procède pour fournir un output réactif:
Observez le diagramme ci-contre, qui décrit un exemple de Shiny app, comprenant
Je vais utiliser cet exemple pour illustrer le fonctionnement de la réactivité des Shiny apps.
Commençons par simplifier et expliquer ce diagramme:
Observez le sens des flèches… Quand un input est modifié, il est aspiré par le contexte réactif… Et non l’inverse (il n’est pas poussé vers le contexte réactif)… Et, oui, la différence est subtile, mais importante pour la suite…
Observez maintenant la couleur de fond du contexte réactif. A gauche, tout est pour le moment en gris, mais par la suite on pourra observer plusieurs états pour les contextes réactifs:
Considérons une première “configuration” de Shiny app. (Avec l’exemple correspondant à droite).
Ici, par défaut, seul output_e est affiché. Il est donc attentif, là où output_d est au contraire inerte.
Notez que quand l’utilisateur change de panel (en affichant “tab1” à la place de “tab2”), c’est au contraire output_d qui est attentif tandis que output_e est inerte…
ui
flowLayout(radioButtons("a","Word 1:", c("Hello","Greetings")),
radioButtons("b","Word 2:", c("benevolent","great")),
radioButtons("c","Word 3:", c("Master","Human"))),
tabsetPanel(tabPanel("tab1",textOutput("d")),
tabPanel("tab2",textOutput("e")),
selected="tab2")
server
output$d <- renderText({Sys.sleep(1);paste(input$a,"!")})
output$e <- renderText({Sys.sleep(1);paste(input$a,",",input$b,input$c,"!")})
Ici j’ai fait en sorte de mettre le système en pause pendant une seconde (Sys.sleep(1)
) pour que vous puissiez bien constater à quel moment le code dans les contextes réactifs est exécuté…
Quand cette app est lancée, voilà donc ce qui se passe:
shows output_e est attentif, donc makes output_e est attentif, et aspire les 3 inputs (qui sont tous nouveaux) afin d’exécuter son code.
Par la suite, l’output qui est attentif est actualisé à chaque fois qu’un de ses inputs (ici par exemple input_b) est modifié…