fix : Review comparaison methode

Tags : fix, doc Pourquoi ? - completer les inforamtions pour eclairer les differentes methodes Quoi ? - completion vignettes/recommandation-pour-l-implementation-de-dsfr - correction orthographe vignettes/documentation-inventaire Tickets ticket #7 #8 #9
spyrales · Jul 20, 2022 · 17ea7ad · 17ea7ad
1 parent 42389df
commit 17ea7ad
Show file tree

Hide file tree

Showing 5 changed files with 70 additions and 17 deletions.
diff --git a/dev/dev_history_package.R b/dev/dev_history_package.R
@@ -8,7 +8,14 @@ attachment::att_amend_desc()
 # Cela est normal : "Error in eval(x, envir = envir) : object 'db_local' not found"
 
 devtools::build_readme()
-devtools::check()
+
+check_n_covr <- function() {
+  res <- devtools::check(args = c("--no-tests"))
+  print(res)
+  covr::package_coverage(type = "tests", quiet = TRUE)
+}
+
+check_n_covr()
 
 # Utils for dev ----
 # Get global variables

diff --git a/dev/flat_compare_dsfr_shiny.Rmd b/dev/flat_compare_dsfr_shiny.Rmd
@@ -108,13 +108,16 @@ 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.
+- 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.
 
 
 ### Option C `From scratch`
 
-Coder l'équivalent de {shiny} (ou quasiment) avec le framework DSFR. Un exemple : <https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/shiny.dsfr> et aussi 
+Coder l'équivalent de la partie 'UI' {shiny} (ou quasiment) avec le framework DSFR.
+La partie 'server' reposera toujours sur la partie {shiny}.
+Un exemple : <https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/shiny.dsfr> et aussi 
 <https://github.com/ThinkR-open/w3css>
 
 Exemple de code pour actionButton :
@@ -202,13 +205,18 @@ Inconvénients:
 - 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}.
+
 ### Option D `from scratch mais pas vraiement`
 
 On pourrait recoder les inputs en conservant les classes CSS qui permettent l'activation du backend JS (comme pour shinyWidgets). 
+
 Exemple pour le actionButton de {shinyWidgets} <https://github.com/dreamRs/shinyWidgets/blob/46359eccb5cfaac80cbe2949da231e3416afcc37/R/actionBttn.R#L63>
 
 Ou pour notre actionButon :
 
+Le fait de lui donner la classe action-button lui permet d'être reconnu par le JS de {shiny} et donc d'avoir une interaction. De même, le fait de lui donner la classe fr-btn en plus, lui permet d'être reconnu par le CSS du DSFR.
+
 ```{r, eval=FALSE}
 library(shiny)
 
@@ -242,19 +250,25 @@ shinyApp(ui, server)
 
 Avantages :
 
-- Permet de reprendre le JS de {shiny} pour les composants DSFR (exemple actionButton)
+- Permet de reprendre le JS de {shiny} pour les composants compatibles DSFR (exemple actionButton)
 
 > Néanmoins, le temps gagné sur les inputs basiques pourrait permettre d'implementer de nouveaux inputs si nécéssaire
 
-- Implementation plus simple
-- Pas besoin de connaissances avancées en JS
+- Implementation 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 
-- Si l'input n'existe pas, alors il faudra recoder la partie JS (c'est vrai pour les options A et B)
+- 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...).
 
+Les changements sont énumérés:
+
+- pour shiny: <https://shiny.rstudio.com/reference/shiny/1.7.0/upgrade.html>
+- pour DSFR: <https://gouvfr.atlassian.net/wiki/spaces/DB/pages/1028030465/Version+1.6.0>
+
+On peut tout à fait imaginer une fonction qui parserait le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}.
 
 ## Les inputs recensés dans les apps "ssm-écologie" par option
 

diff --git a/dev/flat_doc_inventaire.Rmd b/dev/flat_doc_inventaire.Rmd
@@ -63,7 +63,7 @@ De plus, seulement quelques applications utilisent les composantes suivantes:
 
 ```{r, echo = FALSE}
 
-compo_shiny_bonus <- c("fileInput", "dataRangeInput", "showModal")
+compo_shiny_bonus <- c("fileInput", "dateRangeInput", "showModal")
 compo_shiny_bonus
 
 ```

diff --git a/vignettes/documentation-inventaire.Rmd b/vignettes/documentation-inventaire.Rmd
@@ -72,7 +72,7 @@ De plus, seulement quelques applications utilisent les composantes suivantes:
 
 ```{r echo = FALSE}
 
-compo_shiny_bonus <- c("fileInput", "dataRangeInput", "showModal")
+compo_shiny_bonus <- c("fileInput", "dateRangeInput", "showModal")
 compo_shiny_bonus
 
 ```

diff --git a/vignettes/recommandation-pour-l-implementation-de-dsfr.Rmd b/vignettes/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{recommandation-pour-l-implementation-de-dsfr}
   %\VignetteEngine{knitr::rmarkdown}
   %\VignetteEncoding{UTF-8}
 ---
@@ -18,7 +18,7 @@ knitr::opts_chunk$set(
 library(shinygouv)
 ```
 
-<!-- This vignette is generated by fusen: do not edit by hand -->
+<!-- WARNING - This vignette is generated by {fusen} from /dev/flat_compare_dsfr_shiny.Rmd: do not edit by hand -->
 
 ### Comparaison entre les différentes possibilités pour répondre au besoin d'utilisation du framework [DSFR](https://gouvfr.atlassian.net/wiki/spaces/DB/overview?homepageId=145359476)
 
@@ -115,14 +115,17 @@ 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.
+- 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.
 
 
 
 ### Option C `From scratch`
 
-Coder l'équivalent de {shiny} (ou quasiment) avec le framework DSFR. Un exemple : <https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/shiny.dsfr> et aussi 
+Coder l'équivalent de la partie 'UI' {shiny} (ou quasiment) avec le framework DSFR.
+La partie 'server' reposera toujours sur la partie {shiny}.
+Un exemple : <https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/shiny.dsfr> et aussi 
 <https://github.com/ThinkR-open/w3css>
 
 Exemple de code pour actionButton :
@@ -211,14 +214,19 @@ Inconvénients:
 - 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}.
+
 
 ### Option D `from scratch mais pas vraiement`
 
 On pourrait recoder les inputs en conservant les classes CSS qui permettent l'activation du backend JS (comme pour shinyWidgets). 
+
 Exemple pour le actionButton de {shinyWidgets} <https://github.com/dreamRs/shinyWidgets/blob/46359eccb5cfaac80cbe2949da231e3416afcc37/R/actionBttn.R#L63>
 
 Ou pour notre actionButon :
 
+Le fait de lui donner la classe action-button lui permet d'être reconnu par le JS de {shiny} et donc d'avoir une interaction. De même, le fait de lui donner la classe fr-btn en plus, lui permet d'être reconnu par le CSS du DSFR.
+
 
 ```{r eval = FALSE}
 library(shiny)
@@ -236,14 +244,14 @@ actionButton_dsfr <- function(inputId, label){
 ui <- fluidPage(
 
       includeCSS(system.file("dsfr-v1.6.0/dist/dsfr.min.css", package = "shinygouv")),
-      actionButton_dsfr("test", "test"),
-
+      actionButton_dsfr("test", "test")
 )
 
 server <- function(input, output, session) {
   observeEvent(input$test,{
     message(input$test)
   })
+
 }
 
 shinyApp(ui, server)
@@ -252,19 +260,43 @@ shinyApp(ui, server)
 
 Avantages :
 
-- Permet de reprendre le JS de {shiny} pour les composants DSFR (exemple actionButton)
+- Permet de reprendre le JS de {shiny} pour les composants compatibles DSFR (exemple actionButton)
 
 > Néanmoins, le temps gagné sur les inputs basiques pourrait permettre d'implementer de nouveaux inputs si nécéssaire
 
-- Implementation plus simple
-- Pas besoin de connaissances avancées en JS
+- Implementation 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 
-- Si l'input n'existe pas, alors il faudra recoder la partie JS (c'est vrai pour les options A et B)
+- 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...).
 
+Les changements sont énumérés:
+
+- pour shiny: <https://shiny.rstudio.com/reference/shiny/1.7.0/upgrade.html>
+- pour DSFR: <https://gouvfr.atlassian.net/wiki/spaces/DB/pages/1028030465/Version+1.6.0>
+
+On peut tout à fait imaginer une fonction qui parserait le code pour remplacer les appels à {shiny} avec les fonctions {DSFR}.
+
+
+## Les inputs recensés dans les apps "ssm-écologie" par option
+
+```{r echo = FALSE}
+DT::datatable(readxl::read_excel(
+  system.file(
+    "comparaison",
+    "list_input_par_option.xlsx",
+    package = "shinygouv"
+  )
+), 
+options = list("dom" = "tp")
+)
+```
+
+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). 
+
 
 
 ## Notre recommandation