Dashboards em Shiny I

class: center, middle, inverse, title-slide

.title[
# Dashboards em Shiny I
]
.subtitle[
## Reatividade (parte 1)
]
.author[
### <img src = 'https://d33wubrfki0l68.cloudfront.net/9b0699f18268059bdd2e5c21538a29eade7cbd2b/67e5c/img/logo/cursor1-5.png' width = '30%'>
]
.date[
### Setembro de 2023
]

---

## Atividade

Vamos fazer um Shiny app que mostre o resultado do sorteio de `n` números entre 1 e 10, sendo `n` um valor escolhido na UI.

<center>
<img src="https://media.giphy.com/media/JIX9t2j0ZTN9S/giphy.gif" width = "300" height = "300">
 
 
Ao RStudio: 05-amostra-sem-reactive.R
<center>

---
## Reatividade: outro paradigma

Quando escrevemos código R, dois paradigmas estão sempre presentes:

- podemos avaliar uma linha de código assim que a escrevermos; e

- se decidirmos rodar todo o script de uma vez, as linhas de código serão avaliadas sequencialmente.

Isso faz com que as nossas tarefas de análise de dados geralmente virem scripts sequenciais, cujo código não pode ser executado fora de ordem.

No Shiny, utilizamos um outro paradigma de programação.

---
## Exemplo de script sequencial

O código abaixo executa a corriqueira tarefa de importar, manipular e visualizar uma base. Se o código for rodado fora de ordem, nada vai funcionar. Esse paradigma é conhecido como **programação imperativa**.

```r
tab_starwars <- dplyr::starwars

tab_grafico |> 
  ggplot2::ggplot(ggplot2::aes(y = films, x = total_especies)) +
  ggplot2::geom_col() +
  ggplot2::theme_minimal() +
  ggplot2::labs(x = "Total de espécies", y = "Filme")
```

---
## Programação declarativa

Na **programação declarativa**, os comandos não são executados imediatamente. Nosso código funciona como uma receita, que só será utilizada quando necessário.

No contexto do Shiny, a nossa receita será um **um diagrama de reatividade**, isto é, um conjunto de dependências que decide quais outputs devem ser recalculados quando um input muda.

O diagrama de reatividade de um shiny app possui 3 estruturas principais:

- **valores reativos**

- **funções observadoras**

- **expressões reativas**

---
## Valores reativos

Os valores reativos são **a origem do diagrama de reatividade**. Eles guardam as informações que vêm da UI (a partir dos inputs) e disparam *sinais de alerta* sempre que essas informações mudam.

Os valores reativos mais comuns são aqueles dentro da lista `input`.

---
## Funções observadoras

Os *sinais de alerta* disparados por um valor reativo são um aviso dizendo que todos os outputs que dependem dele precisam ser recalculados. O destino desses sinais são as **funções observadoras**. Elas guardam o código de cada output e são o **ponto final do fluxo de reatividade**.

As **funções observadoras** mais comuns são as funções `render*()`.

---
## Expressões reativas

Muitas vezes, um aplicativo shiny precisa de passos intermediários, entre o input de origem e o output final. Isto é, precisamos de uma estrutura que receba um valor reativo, faça alguma conta e devolva um resultado, um valor também reativo que será utilizado posteriormente em uma função observadora.

Essas estruturas são as **expressões reativas**. Para criá-las, podemos utilizar as funções `reactive()` e `eventReactive()`.

---
## A função reactive()

A função `reactive()` pode ser utilizada para criar **expressões reativas**, cujos valores funcionam como um valor reativo. Essa função é muito utilizada para a construção de expressões intermediárias, que podem ser usadas na construção de outputs diferentes.

```r
# server
amostra <- reactive({
 sample(1:10, input$tamanho, replace = TRUE)
})
```

Para acessar o valor dessa expressão reativa, devemos usar parênteses após o nome, como se fosse uma função sem argumentos.

```r
# server
output$summary <- renderPrint({
 amostra() |> 
 table() |> 
 barplot()
})
```

---
## Atividade

Vamos reconstruir nosso app anterior utilizando a função `reactive()` para resolver o problema da amostra.

---
## Contexto reativo

**Valores reativos** e **expressões reativas** só podem ser utilizadas dentro de um **contexto reativo**.

No exemplo abaixo, a função `renderPlot()` cria um contexto reativo e, por isso, podemos utilizar o valor reativo `input$num` dentro dela.

Certo

```r
# server
output$hist <- renderPlot({hist(rnorm(input$num))})
```

Errado

```r
# server
output$hist <- hist(rnorm(input$num))
*#> Error : Can't access reactive value 'tamanho' outside of
*# reactive consumer.
```

---
## Disparo de reatividade

O envio de sinais por parte dos valores reativos, avisando que seus valores estão desatualizados para que as expressões reativas e funções observadoras recalculem seus resultados, só acontece se o **diagrama de reatividade estiver completo**.

Podemos chamar esse envio de **disparo de reatividade**. Ele só acontece para os caminhos do diagrama de reatividade que começam com um valor reativo e terminam com uma função observadora. **Caminhos que terminam com expressões reativas não causam o disparo de reatividade**.

---
## Atividade

Vamos olhar mais de perto o contexto reativo e o disparo de reatividade.

---
## Gráfico de reatividade

Você pode gerar um gráfico de reatividade do seu aplicativo utilizando o pacote `reactlog`. Com o pacote instalado, basta rodar o seguinte comando no Console

```r
options(shiny.reactlog = TRUE) 
```

e então, dentro do app, utilizar o comando `CTRL + F3` (no Mac, `command + F3`).

---
## Atividade

Vamos olhar o gráfico de reatividade do nosso app `06-amostra-com-reactive.R`.

---
## A função eventReactive()

Enquanto a função `reactive()` observa mudanças em todos os valores reativos presentes no código dela, a função `eventReactive()` observa mudanças em apenas um valor reativo, especificado na chamada da própria função.

```r
# ui
actionButton("atualizar", "Gerar gráfico")
```

```r
# server
titulo <- eventReactive(input$atualizar, {
 input$titulo
})

output$hist <- renderPlot({
 hist(amostra(), main = titulo())
})
```

---
## Atividade

Vamos criar um botão para atualizar o título do gráfico apenas quando clicarmos nele.