Une app {shiny} est une page unique : une url, une UI, une fonction server. Tant que l’app reste petite, c’est confortable. Dès qu’on veut un vrai site — une page d’accueil, une page contact, une page par utilisateur, des urls qu’on peut envoyer par mail ou mettre en favori — on se met à simuler des pages à coups d’onglets et de conditionalPanel().
{brochure} prend le problème dans l’autre sens : chaque page est une vraie page, avec son url, son UI, sa fonction server et sa propre session Shiny.
install.packages("brochure")library(shiny)
library(brochure)
brochureApp(
page(
href = "/",
ui = fluidPage(
h1("Accueil"),
tags$a(href = "/contact", "Nous contacter")
),
server = function(input, output, session) {
# ...
}
),
page(
href = "/contact",
ui = fluidPage(h1("Contact"))
)
)Vous lancez l’app comme n’importe quelle app Shiny, et naviguer d’une page à l’autre est un simple lien. Une url peut aussi contenir un paramètre — /user/:id, que la page relit avec get_keys().
Autour de ça, {brochure} donne accès à ce qu’on attend d’un serveur web : des handlers de requête et de réponse pour journaliser, servir un healthcheck ou répondre avant Shiny, des helpers pour poser et lire des cookies (et donc porter un état d’une page à l’autre), des redirections, et de quoi servir l’app derrière un reverse proxy ou sur Posit Connect.
En contrepartie, on quitte le paradigme single page : rien de ce qui est calculé sur une page ne survit à la navigation vers une autre. C’est le sujet de vignette("design"), à lire avant de se lancer.
L’article complet, les exemples et les changements de cette version :
👉 {brochure} 1.0.0 is now on CRAN
Documentation : colinfay.me/brochure.
