diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 106fd01..48162a2 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -59,7 +59,7 @@ representative at an online or offline event. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported to the community leaders responsible for enforcement at juliette.engelaere-lefebvre@developpement-durable.gouv.fr. +reported to the community leaders responsible for enforcement at juliette.engelaere@developpement-durable.gouv.fr. All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the diff --git a/DESCRIPTION b/DESCRIPTION index 044003f..c1ce060 100644 --- a/DESCRIPTION +++ b/DESCRIPTION @@ -2,7 +2,7 @@ Package: shinygouv Title: Implement the DSFR for your shiny applications Version: 1.0.2 Authors@R: c( - person("Juliette", "ENGELARE-LEFEBVRE", , "juliette.engelaere-lefebvre@developpement-durable.gouv.fr", role = c("aut", "cre")), + person("Juliette", "ENGELAERE-LEFEBVRE", , "juliette.engelaere-lefebvre@developpement-durable.gouv.fr", role = c("aut", "cre")), person("Sébastien", "Rochette", , "sebastien@thinkr.fr", role = "aut", comment = c(ORCID = "0000-0002-1565-9313")), person("Murielle", "Delmotte", , "murielle@thinkr.fr", role = "aut", @@ -11,6 +11,7 @@ Authors@R: c( comment = c(ORCID = "0000-0002-4816-4624")), person("Yohann", "Mansiaux", , "yohann@thinkr.fr", role = "aut", comment = c(ORCID = "0000-0002-8905-6603")), + person("Jean-Daniel", "LOMENEDE", , "jean-daniel.lomenede@seine-maritime.gouv.fr", role = "aut"), person("David", "Granjon", role = "ctb"), person("Alan", "Dipert", role = "ctb") ) diff --git a/R/run_app.R b/R/run_app.R index bd1e4ea..d245b14 100644 --- a/R/run_app.R +++ b/R/run_app.R @@ -1,4 +1,4 @@ -#' Run the Shiny Application +#' Run the shinygouv-demo Application #' #' @param ... arguments to pass to golem_opts. #' See `?golem::get_golem_options` for more details. diff --git a/README.Rmd b/README.Rmd index 91c4d23..1d544b9 100644 --- a/README.Rmd +++ b/README.Rmd @@ -15,7 +15,7 @@ knitr::opts_chunk$set( # {shinygouv} -Le package {shinygouv} permet d'utiliser le template existant pour le `Système de Design de l'Etat` (DSFR) dans vos applications Shiny. +Le package {shinygouv} permet d'utiliser le [`Système de Design de l'Etat` (DSFR)](https://www.systeme-de-design.gouv.fr/) dans vos applications Shiny. Il s'installe depuis github : @@ -54,9 +54,10 @@ shinyApp( ``` -# Visualiser un application de démonstration comprenant les composants déjà implémentés: +# Visualiser une application de démonstration comprenant les composants déjà implémentés: [shinygouv-demo](https://ssm-ecologie.shinyapps.io/shinygouv-demo/) +[shinygouv-demo version de dev](https://ssm-ecologie.shinyapps.io/shinygouv-demo-dev/) # Contribuer au développement du package @@ -64,4 +65,6 @@ Voir les vignettes à l'intention des développeurs du [site de présentation d # Code of Conduct -Please note that the {shinygouv} project is released with a Contributor Code of Conduct. By contributing to this project, you agree to abide by its terms. +Notez svp qu'un Code de conduite ([Contributor Code of Conduct](https://spyrales.github.io/shinygouv/CODE_OF_CONDUCT.html)) encadre la participation au projet {shinygouv}. + +En contribuant à ce projet, vous acceptez de le respecter. diff --git a/app.R b/app.R index 2436da1..6083395 100644 --- a/app.R +++ b/app.R @@ -1,4 +1,4 @@ -# Launch the ShinyApp (Do not remove this comment) +# Launch the ShinyApp shinygouv-demo (Do not remove this comment) # To deploy, run: rsconnect::deployApp() # Or use the blue button on top of this file diff --git a/dev/flat_composants/flat_new_one.Rmd b/dev/flat_composants/flat_new_one.Rmd index de710e6..9e7293b 100644 --- a/dev/flat_composants/flat_new_one.Rmd +++ b/dev/flat_composants/flat_new_one.Rmd @@ -1,5 +1,5 @@ --- -title: "flat_new_one.Rmd empty" +title: "flat_nom_composant_shiny.Rmd empty" output: html_document editor_options: chunk_output_type: console diff --git a/inst/test.convert.dsfr/DESCRIPTION b/inst/test.convert.dsfr/DESCRIPTION index 7ec389f..aa3ab01 100644 --- a/inst/test.convert.dsfr/DESCRIPTION +++ b/inst/test.convert.dsfr/DESCRIPTION @@ -1,9 +1,9 @@ Package: test.convert.dsfr -Title: PKG_TITLE +Title: App Shiny Test Convert DSFR Version: 0.0.0.9000 Authors@R: person("AUTHOR_FIRST", "AUTHOR_LAST", , "AUTHOR@MAIL.COM", role = c("cre", "aut")) -Description: PKG_DESC. +Description: App shiny test.convert.dsfr pour tester convert_to_dsfr(). License: MIT + file LICENSE Imports: config (>= 0.3.1), diff --git a/vignettes/A-convertir-une-app-shiny-en-app-shiny-dsfr.Rmd b/vignettes/A-convertir-une-app-shiny-en-app-shiny-dsfr.Rmd index 0c2eec9..86180d8 100644 --- a/vignettes/A-convertir-une-app-shiny-en-app-shiny-dsfr.Rmd +++ b/vignettes/A-convertir-une-app-shiny-en-app-shiny-dsfr.Rmd @@ -18,69 +18,79 @@ knitr::opts_chunk$set( library(shinygouv) ``` -# convert_to_dsfr +# Fonction `convert_to_dsfr()` -La fonction expérimentale `convert_to_dsfr()` convertit tous les composants shiny présents dans les fichiers du dossier "R/" d'une application shiny, en composant dsfr, si et seulement si ceux ci ont été implémentés dans la {version} définie en paramètre. +La fonction `convert_to_dsfr()` a été pensée pour faciliter la conversion d'applications Shiny existantes au Design system de l'Etat. -Cette fonction va modifier les fichiers de votre application, présents dans le répertoire `path`. -Il reste des points de vigilances sur la conversion des tabPanel dans les navbarPage et les tabsetPanel. +## Principe : Réécriture d'une application existante -## Table de correspondance +La fonction `convert_to_dsfr()` convertit tous les composants shiny présents dans les fichiers du dossier "R/" d'une application shiny, en composant shinygouv dsfr, dès lors qu'ils existent et qu'ils ont été implémentés dans le package, pour la {version} définie en paramètre. -Elle se base alors sur la table de correspondance des composants implémentés : -Par exemple pour la version "1.7.2" ([v1.7.2/table_correspondance_shiny_dsfr.csv](https://github.com/spyrales/shinygouv/blob/main/inst/v1.7.2/table_correspondance_shiny_dsfr.csv)) +Attention, cette fonction modifie les fonctions des composants UI de votre application existante. +Pour un simple test, appliquez là sur une copie. +Il reste des points de vigilances sur la conversion des tabPanel dans les navbarPage et les tabsetPanel. +Cette fonction est encore expérimentale. -```{r echo = FALSE, message = FALSE} -read.csv2( - system.file("v1.7.2/table_correspondance_shiny_dsfr.csv", package = "shinygouv") -) %>% - DT::datatable() -``` ## Dépendances -De plus, elle ajoute la dépendance au package {shinygouv} dans le fichier `app_ui.R` +Le fonction `convert_to_dsfr()` ajoute automatiquement la dépendance au package {shinygouv} dans le fichier `app_ui.R` de votre application shiny Golem. +Dans le cadre d'une application non packagée avec {golem}, vous devrez ajouter à la main la dépendance à {shinygouv}, souvent avec un `library(shinygouv)` dans votre fichier global.R. -## Conversion -Pour cela, il suffit de lancer dans la console depuis votre projet contenant l'application shiny : +## Conversion +La conversion est réalisée en lançant dans la console, depuis votre projet contenant l'application shiny : ```{r eval = FALSE} convert_to_dsfr() ``` -Si l'ensemble des scripts `.R` de votre application ne se trouve pas dans un dossier "R/" à la racine de votre projet, vous pouvez passer en argument le `path` du dossier contenant l'ensemble de ces fichiers. -Comme par exemple: +Si l'ensemble des scripts `.R` de votre application ne se trouvent pas dans un dossier "R/" à la racine de votre projet, vous pouvez passer en argument le `path` du dossier contenant l'ensemble de ces fichiers. +Comme par exemple: ```{r eval = FALSE} convert_to_dsfr(path = "le_chemin_de_mon_application") ``` -*Attention*, dans le cadre d'une application hors {golem}, vous devrez ajouter la dépendance à {shinygouv} pour que votre application puisse utiliser les composants dsfr - - -```{r examples-convert_to_dsfr} -if (FALSE) { - mydir <- tempfile(pattern = "app") - dir.create(mydir) - golem::install_dev_deps( - force_install = TRUE - ) - golem::create_golem( - mydir, - overwrite = TRUE, - open = FALSE - ) - convert_to_dsfr(path = file.path(mydir, "R")) -} +*Attention*, dans le cadre d'une application simple (hors {golem}), vous devrez ajouter la dépendance à {shinygouv} pour que votre application puisse utiliser les composants dsfr (avec `library(shingouv)`). + + +## Table de correspondance + +Elle se base alors sur la table de correspondance des composants implémentés : + +Par exemple pour la version "1.7.2" ([v1.7.2/table_correspondance_shiny_dsfr.csv](https://github.com/spyrales/shinygouv/blob/main/inst/v1.7.2/table_correspondance_shiny_dsfr.csv)) + + +```{r echo = FALSE, message = FALSE} +read.csv2( + system.file("v1.7.2/table_correspondance_shiny_dsfr.csv", package = "shinygouv") +) %>% + DT::datatable() +``` + +# Quels sont les composants implémentés dans {shinygouv} ? + +Les composants d'interface utilisateur implémentés dans `{shinygouv}` et leur correspondance avec les fonctions habituelles de `{Shiny}` sont listées ici : + + +```{r echo = FALSE, message = FALSE} +read.csv2( + system.file(get_dsfr_version(with_v = TRUE), "/table_correspondance_shiny_dsfr.csv", package = "shinygouv") +) %>% + dplyr::select(composant_shiny, composant_dsfr) %>% + DT::datatable() ``` +Ils ne sont pas encore très nombreux et peuvent être améliorés, n'hésitez pas à contribuer, un guide est là pour vous aider à rejoindre les auteurs de {shinygouv} ! + + # Connaître la version du dsfr actuelle Pour savoir quelle version du dsfr est utilisée dans votre installation de {shinygouv}, vous pouvez exécuter `get_dsfr_version()` diff --git a/vignettes/Dev-A-guide-du-developpeur.Rmd b/vignettes/Dev-A-guide-du-developpeur.Rmd index 57a2495..3fbba24 100644 --- a/vignettes/Dev-A-guide-du-developpeur.Rmd +++ b/vignettes/Dev-A-guide-du-developpeur.Rmd @@ -13,6 +13,10 @@ knitr::opts_chunk$set(echo = TRUE, eval = FALSE) Ceci est un dossier de documentation dédié aux développeurs et développeuses. + +## Contribuer à {shinygouv} - Introduction +Pour des contributions au code de ce projet, svp regardez le guide général de contribution à https://spyrales.github.io/shinygouv/CONTRIBUTING.html + ## Structuration du repo (a compléter) Le développement de ce package a été réalisé [avec {fusen}](https://thinkr-open.github.io/fusen/) : les fonctions, vignettes et test sont générées par des fichiers Rmd dans le dossier /dev. diff --git a/vignettes/Dev-B-comment-faire-un-composant-shiny.Rmd b/vignettes/Dev-B-comment-faire-un-composant-shiny.Rmd index 84adc94..443ad1c 100644 --- a/vignettes/Dev-B-comment-faire-un-composant-shiny.Rmd +++ b/vignettes/Dev-B-comment-faire-un-composant-shiny.Rmd @@ -46,9 +46,12 @@ _Ici nous prenons l'exemple d'un composant développé pour la version 1.7.2 du #### Première étape -- Copier dans le dossier `inst/v1.7.2/composant` le template html du bouton pour dsfr - - Se rendre sur - - Enregistrer le code html par défaut du bouton dans un fichier `inst/v1.7.2/composant/bouton.html` +- Copier dans le dossier `inst/v1.7.2/composant` le template html du bouton pour dsfr + + - Se rendre sur + + - Enregistrer le code html par défaut du bouton dans un fichier `inst/v1.7.2/composant/bouton.html` + ``` @@ -57,10 +60,11 @@ _Ici nous prenons l'exemple d'un composant développé pour la version 1.7.2 du #### Deuxième étape -- Modifier le code html pour mettre les paramètres nécessaires à son bon fonctionnement dans {shiny} - - Ajouter un `id` pour le futur `inputId` - - Ajouter la classe permettant de déclencher l’évènement côté {shiny} - - Ajouter/Remplacer aussi les autres paramètres nécessaires à la personnalisation du composant +- Modifier le code html pour mettre les paramètres nécessaires à son bon fonctionnement dans {shiny} + + - Ajouter un `id` pour le futur `inputId` + - Ajouter la classe permettant de déclencher l'évènement côté {shiny} + - Ajouter/Remplacer aussi les autres paramètres nécessaires à la personnalisation du composant Après retravail sur le composant `actionButton()`, voici son template html: @@ -74,7 +78,7 @@ Après retravail sur le composant `actionButton()`, voici son template html: Dans notre cas, nous traitons le `actionButton()` et la classe a ajouter est `action-button`. Comment savoir ? -Le plus simple est d'exécuter la fonction de l'input dans shiny dans la console: +Le plus simple est d'exécuter la fonction de l'input dans shiny dans la console : ```{r eval = FALSE} shiny::actionButton("test", "test") @@ -84,7 +88,11 @@ shiny::actionButton("test", "test") `` ``` -> On observe alors que dans "class" nous avons des classes liées à bootstrap `btn-*` et une classe à part `action-button`. C'est souvent cette classe qui permet de déclencher l’évènement coté server. Si cela n'est pas suffisant, il faudra chercher dans le code du package {shiny}. Le code se trouve [ici](https://github.com/rstudio/shiny/tree/main/srcts/src/bindings/input) et en ouvrant le fichier `.ts` vous trouverez alors un endroit ou on recherche la classe qui active l'input : +> On observe alors que dans "class" nous avons des classes liées à bootstrap `btn-*` et une classe à part `action-button`. +> C'est souvent cette classe qui permet de déclencher l’évènement coté server. +> Si cela n'est pas suffisant, il faudra chercher dans le code du package {shiny}. +Le code se trouve [ici](https://github.com/rstudio/shiny/tree/main/srcts/src/bindings/input) et en ouvrant le fichier `.ts` vous trouverez alors un endroit ou on recherche la classe qui active l'input : + ``` find(scope: HTMLElement): JQuery { return $(scope).find(".action-button"); @@ -94,14 +102,15 @@ shiny::actionButton("test", "test") #### Troisième étape -- Créer la fonction qui permettra d'utiliser ce nouveau bouton. - - Copier coller le flat se trouvant dans [dev/flat_composants/flat_new_one.Rmd](https://github.com/spyrales/shinygouv/blob/main/dev/flat_composants/flat_new_one.Rmd) dans - `dev/flat_composants/` et le renommer "flat_nom_du_composant_shiny.Rmd". Dans cet exemple, `flat_actionButton.Rmd` - - Dans votre nouveau flat, il faut remplacer "nom_composant_shiny" par le nom du composant shiny (dans cet exemple, `actionButton`) - - Changer le chemin du fichier de votre `.html` dans la fonction `*_template` - - Compléter les paramètres et leur documentation dans vos fonctions selon la personnalisation de votre `.html` - - Adapter les tests unitaires en fonction des paramètres choisis (y compris la date du snapshot). - - Puis lancer le dernier chunck `fusen::inflate()` +- Créer la fonction qui permettra d'utiliser ce nouveau bouton : + + - Copier/coller le flat se trouvant dans [dev/flat_composants/flat_new_one.Rmd](https://github.com/spyrales/shinygouv/blob/main/dev/flat_composants/flat_new_one.Rmd) dans + `dev/flat_composants/` et le renommer "flat_nom_du_composant_shiny.Rmd". Dans cet exemple, `flat_actionButton.Rmd`. + - Dans votre nouveau flat, il faut remplacer "nom_composant_shiny" par le nom du composant shiny (dans cet exemple, `actionButton`). + - Changer le chemin du fichier de votre `.html` dans la fonction `*_template`. + - Compléter les paramètres et leur documentation dans vos fonctions selon la personnalisation de votre `.html`. + - Adapter les tests unitaires en fonction des paramètres choisis (y compris la date du snapshot). + - Puis lancer le dernier chunk `fusen::inflate()`. Voir exemple [dev/flat_composants/flat_actionButton.Rmd](https://github.com/spyrales/shinygouv/blob/main/dev/flat_composants/flat_actionButton.Rmd) @@ -112,12 +121,12 @@ Ayez une attention particulière pour les tests unitaires qui sont la garantie d #### Quatrième étape -- Créer la fonction qui permettra de mettre à jour votre input (si nécessaire). -- Certains composants comme l'actionButton() n'ont pas besoin de mise à jour, c'est le cas pour beaucoup d'autres composants. -- Certains fonctions de mise à jour de composants correspondent en fait à l'appel de la fonction native `{shiny}` correspondante (voir par ex `updateNumericInput_dsfr()`). -- Pour certains composants non présents nativement dans `{shiny}`, des implémentations adhoc ont dû être réalisées (voir par ex `updateRadioGroupButtons_dsfr()`). - + Dans ce cas précis il faut être vigilant sur l'utilisation de la fonction `ns()` dans le nom des inputId. Il est indispensable de prendre en compte la fonction `ns()` partout, sauf dans le cas d'un appel à la fonction shiny `session$sendInputMessage()` car le ns() est géré en interne. Le plus simple reste d'observer la fonction `updateRadioGroupButtons_dsfr()`. - +- Créer la fonction qui permettra de mettre à jour votre input (si nécessaire). +- Certains composants comme l' `actionButton()` n'ont pas besoin de mise à jour, c'est le cas pour beaucoup d'autres composants. +- Certains fonctions de mise à jour de composants correspondent en fait à l'appel de la fonction native `{shiny}` correspondante (voir par ex `updateNumericInput_dsfr()`). +- Pour certains composants non présents nativement dans `{shiny}`, des implémentations adhoc ont dû être réalisées (voir par ex `updateRadioGroupButtons_dsfr()`). + + Dans ce cas précis il faut être vigilant sur l'utilisation de la fonction `ns()` dans le nom des inputId. Il est indispensable de prendre en compte la fonction `ns()` partout, sauf dans le cas d'un appel à la fonction shiny `session$sendInputMessage()` car le ns() est géré en interne. Le plus simple reste d'observer la fonction `updateRadioGroupButtons_dsfr()`. + #### Cinquième étape @@ -129,4 +138,4 @@ La colonne `composant_shiny` restera vide si le composant dsfr n'a pas d'équiva Cette table de correspondance permettra le bon déroulement de la conversion d'une app shiny en une app shiny dsfr (en utilisant `convert_to_dsfr()`) - +Vous pouvez également ajouter votre composant dans l'[application de démonstration]("https://github.com/spyrales/shinygouv/tree/main/dev/R). diff --git a/vignettes/Dev-D-Faire-tourner-les-applications-shiny-du-package-shinygouv.Rmd b/vignettes/Dev-D-Faire-tourner-les-applications-shiny-du-package-shinygouv.Rmd new file mode 100644 index 0000000..2fe0716 --- /dev/null +++ b/vignettes/Dev-D-Faire-tourner-les-applications-shiny-du-package-shinygouv.Rmd @@ -0,0 +1,57 @@ +--- +title: "Faire tourner les applications shiny du package shinygouv" +output: github_document +vignette: > + %\VignetteIndexEntry{Dev-D-Faire-tourner-les-applications-shiny-du-package-shinygouv} + %\VignetteEngine{knitr::rmarkdown} + %\VignetteEncoding{UTF-8} +--- + +```{r setup, include = FALSE} +knitr::opts_chunk$set( + collapse = TRUE, + comment = "#>" +) +``` + +Ce package contient 2 applications shiny Golem : + +- une première application au design classique a été placée dans [inst/test.convert.dsfr]("https://github.com/spyrales/shinygouv/tree/main/inst/inst/test.convert.dsfr), pour tester la fonction de conversion `convert_to_dsfr()` ; +- une seconde application, mise au design DSFR, permet de visualiser les composants de `{shinygouv}`, elle déployée par intégration continue. + +## Application au design classique inst/test.convert.dsfr + +Pour faire fonctionner localement l'app Shiny incluse dans "inst/", il faut lancer: +```{r eval = FALSE} +withr::with_dir("inst/inst/test.convert.dsfr/", { + pkgload::load_all(export_all = FALSE, helpers = FALSE, attach_testthat = FALSE, quiet = TRUE) + test.convert.dsfr::run_app() +}) +``` + +Et pour tester la conversion à la volée avec +```{r eval = FALSE} +pkgload::load_all() +mydir <- tempfile(pattern = "app") +fs::dir_copy("inst/test.convert.dsfr/", mydir) +withr::with_dir(mydir, { + convert_to_dsfr() + pkgload::load_all(export_all = FALSE, helpers = FALSE, attach_testthat = FALSE, quiet = TRUE) + test.convert.dsfr::run_app() +}) +``` + +## Application de demo du package + +Le package `{shinygouv}` contient une application de démo, qui permet de visualiser les composants implémentés. + +Elle peut être lancée en local avec : + +```{r eval=FALSE} +shinygouv::run_app() +``` + +Cette application est déployée par intégration continue sur : + +- https://ssm-ecologie.shinyapps.io/shinygouv-demo/ pour la branche principale, en production +- https://ssm-ecologie.shinyapps.io/shinygouv-demo-dev/ pour la branche de dev diff --git a/vignettes/Dev-G-test-and-coverage.Rmd b/vignettes/Dev-G-test-and-coverage.Rmd index 6b0e9a6..3380b61 100644 --- a/vignettes/Dev-G-test-and-coverage.Rmd +++ b/vignettes/Dev-G-test-and-coverage.Rmd @@ -140,3 +140,20 @@ Session Info + + +## Description of coverage report + +- Total coverage percentage, this is the total number of lines covered by a test divided by the total number of lines requiring testing. +- File = Name of the file, the code coverage is calculated per file. +- Lines = Number of lines in the file, corresponds to the number of lines inside the file. +- Relevant = Corresponds to the lines of code to be tested (i.e. the lines inside the function brackets with the brackets and comments removed). +- Covered = Number of lines covered by a test +- Missed = Number of lines not covered by a test +- Hits/Line = Corresponds to the average number of times specific lines are tested in the file. + + In other words, if I have an 11-lines file where (1) the first 6 lines are tested 4 times, (2) the seventh is tested 1 time, (3) the last 4 are tested 10 times. The calculation is then: ((6 * 4) + 1 + (10 * 4))/11 = 6. This gives the average number of times a line is tested, here 6. +- Coverage = corresponds to the percentage of lines covered by a test. Calculation: Covered / Relevant * 100, number of lines covered by a test divided by the number of lines requiring testing. +- If we go into detail by file, the color code is as follows: + - green line = line tested by at least one test (the x? corresponds to the number of times the line is tested) + - red line = line not covered by a test + - white line = lines not to be tested (comments, ...) diff --git a/vignettes/Hist-A-recommandation-pour-l-implementation-de-dsfr.Rmd b/vignettes/Hist-A-recommandation-pour-l-implementation-de-dsfr.Rmd index 94f89fd..cb59c92 100644 --- a/vignettes/Hist-A-recommandation-pour-l-implementation-de-dsfr.Rmd +++ b/vignettes/Hist-A-recommandation-pour-l-implementation-de-dsfr.Rmd @@ -2,7 +2,7 @@ title: "Recommandation pour l'implementation de DSFR" output: rmarkdown::html_vignette vignette: > - %\VignetteIndexEntry{recommandation-pour-l-implementation-de-dsfr} + %\VignetteIndexEntry{Hist-A-recommandation-pour-l-implementation-de-dsfr} %\VignetteEngine{knitr::rmarkdown} %\VignetteEncoding{UTF-8} --- @@ -44,7 +44,7 @@ DT::datatable( ### Option A {shiny} + {bslib} : -Utiliser les fonctionalités de {bslib} pour utiliser le framework DSFR. +Utiliser les fonctionnalités de {bslib} pour utiliser le framework DSFR. Avantages : @@ -53,8 +53,8 @@ Avantages : Inconvénients: -- Limiter par les paramètres modifiables. -- Nécéssiterait de transformer le CSS de DSFR pour une compatibilité avec bootstrap (ce qui semble être un non-sens :)). +- Limité par les paramètres modifiables. +- Nécessiterait de transformer le CSS de DSFR pour une compatibilité avec bootstrap (ce qui semble être un non-sens :)). - Il faut maintenir le thème DSFR qui est le résultat de la transformation du CSS. Donc une connaissance assez élevée sur bootstrap et DSFR. ThinkR ne peut garantir le succès de cette méthode. Cette méthode n'a jamais été expérimentée. @@ -115,7 +115,7 @@ Avantages: Inconvénients: -- Limiter par ce que propose {shiny}. On ne peut appliquer que les classes DSFR qui ont un équivalent déjà existantes dans bootstrap. +- Limité par ce que propose {shiny}. On ne peut appliquer que les classes DSFR qui ont un équivalent déjà existantes dans bootstrap. - Cela réécrit le code au lancement de l'application et peut donc altérer l'expérience utilisateur. - Ne permet pas d'appliquer les règles d'utilisations des différents composants de DSFR. - Double travail : il faut maintenir un tableau de correspondance entre les deux frameworks. Donc une connaissance assez élevée sur les deux. @@ -201,7 +201,7 @@ server <- function(input, output, session) { shinyApp(ui, server) ``` -Ceci sera transformé en fonction et documenter dans un package +Ceci sera transformé en fonction et documenté dans un package Avantages : @@ -212,14 +212,14 @@ Avantages : Inconvénients: -- Nécéssite plus de développement et donc de temps +- Nécessite plus de développement et donc de temps - Oblige les utilisateurs à remplacer les fonctions {shiny} par les fonctions DSFR - Bonne connaissance en JS pour maintenir le package -On peut tout à fait imaginer une fonction qui parserait le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}. +On peut tout à fait imaginer une fonction qui parcourt le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}. -### Option D `from scratch mais pas vraiement` +### Option D `from scratch mais pas vraiment` On pourrait recoder les inputs en conservant les classes CSS qui permettent l'activation du backend JS (comme pour shinyWidgets). @@ -227,7 +227,7 @@ Exemple pour le actionButton de {shinyWidgets} Néanmoins, le temps gagné sur les inputs basiques pourrait permettre d'implementer de nouveaux inputs si nécéssaire -- Implementation plus simple pour les composants compatibles. +- Implémentation plus simple pour les composants compatibles. - Pas besoin de connaissances avancées en JS pour les composants compatibles. Inconvénients : -- Liée au package {shiny} et aux inputs implémentés +- Lié au package {shiny} et aux inputs implémentés - Si l'input n'existe pas dans {shiny}, alors il faudra recoder la partie JS (c'est vrai pour les options A et B) - Maintenance : suivre {shiny} et DSFR. Autrement dit, si la classe de l'input {shiny} devient autre chose que `action-button` notre code ne marchera plus (peu probable...). @@ -278,7 +278,7 @@ Les changements sont énumérés: - pour shiny: - pour DSFR: -On peut tout à fait imaginer une fonction qui parserait le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}. +On peut tout à fait imaginer une fonction qui parcourt le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}. ## Les inputs recensés dans les apps "ssm-écologie" par option @@ -296,7 +296,8 @@ DT::datatable( ) ``` -Les éléments tels que navbarpage, tabpanel etc sont possible dans la limite de ce que propose DSFR. Ils nécéssitent plus ou moins une demi-journée par composant (codé avec des htmlTemplates). +Les éléments tels que `navbarPage()`, `tabPanel()` etc sont possibles dans la limite de ce que propose le DSFR. +Ils nécessitent plus ou moins une demi-journée par composant (codé avec des htmlTemplates). @@ -304,6 +305,6 @@ Les éléments tels que navbarpage, tabpanel etc sont possible dans la limite de Nous préconisons l'**option D**. Pourquoi ? -Cette approche permet de mettre en avant le travail réalisé sur le framework DSFR avec une implementation possible de l'intégralité des fonctionnalités sans la contrainte et la lourdeur de connaitre le JS. Elle permet aussi de faciliter la maintenance du package par les futures mainteneurs. Bien que cette option ne réponde pas directement à l'objectif : `éviter d'avoir des fonctions spécifiques pour ne pas géner le passage d'un template à un autre`, on peut tout à fait imaginer une fonction qui parserait le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}. - - +Cette approche permet de mettre en avant le travail réalisé sur le framework DSFR avec une implémentation possible de l'intégralité des fonctionnalités sans la contrainte et la lourdeur de connaitre le JS. +Elle permet aussi de faciliter la maintenance du package par les futures mainteneurs. +Bien que cette option ne réponde pas directement à l'objectif : `éviter d'avoir des fonctions spécifiques pour ne pas géner le passage d'un template à un autre`, on peut tout à fait imaginer une fonction qui parcourt le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}. diff --git a/vignettes/Hist-B-documentation-inventaire.Rmd b/vignettes/Hist-B-documentation-inventaire.Rmd index ab36938..4b20de2 100644 --- a/vignettes/Hist-B-documentation-inventaire.Rmd +++ b/vignettes/Hist-B-documentation-inventaire.Rmd @@ -2,7 +2,7 @@ title: "Documentation-Inventaire" output: rmarkdown::html_vignette vignette: > - %\VignetteIndexEntry{Dev-F-documentation-inventaire} + %\VignetteIndexEntry{Hist-B-documentation-inventaire} %\VignetteEngine{knitr::rmarkdown} %\VignetteEncoding{UTF-8} --- diff --git a/vignettes/Hist-C-retour-sur-shiny.dsfr.Rmd b/vignettes/Hist-C-retour-sur-shiny.dsfr.Rmd index f702967..cf6d615 100644 --- a/vignettes/Hist-C-retour-sur-shiny.dsfr.Rmd +++ b/vignettes/Hist-C-retour-sur-shiny.dsfr.Rmd @@ -2,7 +2,7 @@ title: 'Retour sur shiny.dsfr' output: github_document vignette: > - %\VignetteIndexEntry{Dev-D-retour-sur-shiny.dsfr} + %\VignetteIndexEntry{Hist-C-retour-sur-shiny.dsfr} %\VignetteEngine{knitr::rmarkdown} %\VignetteEncoding{UTF-8} --- @@ -17,10 +17,12 @@ Le package {shiny.dsfr} disponible [ici](https://gitlab-forge.din.developpement- Cependant, cette méthode oblige le développeur à convertir le code HTML fourni par le framework dsfr en R, pour ensuite devoir le retraduire en html pour shiny. -Suite à la recommandation adoptée par le client, à savoir l'option D de la vignette `Recommandation`, voici les différents points d'explication sur la méthodologie complémentaire retenue par nos soins en comparaison de {shiny.dsfr} : +Suite à la recommandation adoptée par le client, à savoir l'option D de la vignette [Recommandation](Hist-A-recommandation-pour-l-implementation-de-dsfr), voici les différents points d'explication sur la méthodologie complémentaire retenue par nos soins en comparaison de {shiny.dsfr} : - Premièrement, nous privilégions une approche différente pour ce package en utilisant directement les codes html et htmlTemplate. L'avantage est de ne pas traduire le code html en R, la fonction htmlTemplate le fait pour nous. Cela permettra de maintenir seulement les différents fichiers `.html`. Ensuite, une batterie d'outils sera à disposition du développeur pour créer les fonctions qui exploiteront ces fichiers `html`. -- Deuxièment, dans la mesure du possible, nous souhaiterions ne pas avoir à recoder les `inputs-bindings` de shiny. Pour cela, on réutilisera les classes déjà existantes dans {shiny}. +- Deuxièmement, dans la mesure du possible, nous souhaiterions ne pas avoir à recoder les `inputs-bindings` de shiny. Pour cela, on réutilisera les classes déjà existantes dans {shiny}. -Néanmoins, nous allons nous inspirer du package {shiny.dsfr} qui apporte une logique métier dans certains composants déjà implementés. Par exemple, la gestion de la dépendance avec {bootstrap}. Autrement dit, nous allons reprendre le travail déjà réalisé par Jean-Daniel Lomenede en remplaçant le code {shiny} par des html templates. +Néanmoins, nous allons nous inspirer du package {shiny.dsfr} qui apporte une logique métier dans certains composants déjà implémentes. +Par exemple, la gestion de la dépendance avec {bootstrap}. +Autrement dit, nous allons reprendre le travail déjà réalisé par Jean-Daniel Lomenede en remplaçant le code {shiny} par des html templates.