Skip to content

Commit

Permalink
Passage des vignettes sur les choix historiques dans un 3e menu : ell…
Browse files Browse the repository at this point in the history
…es n'ont plus vocation à bouger et ne sont pas absoluement nécessaires au candidat mainteneur

- fix typo
- passage sur les lagues à latoute fin, moins important que le worflow avant de comiter
  • Loading branch information
jengelaere committed Jul 19, 2023
1 parent 1302996 commit d888a87
Show file tree
Hide file tree
Showing 7 changed files with 47 additions and 28 deletions.
5 changes: 5 additions & 0 deletions _pkgdown.yml
Original file line number Diff line number Diff line change
Expand Up @@ -11,3 +11,8 @@ articles:
desc: Vignettes à l'intention des mainteneurs de `{shingouv}`
contents:
- starts_with("Dev")

- title: Orientations initiales de développement
desc: Notes à l'intention des mainteneurs de `{shingouv}` curieux de comprendre son histoire
contents:
- starts_with("Hist")
36 changes: 19 additions & 17 deletions vignettes/Dev-A-guide-du-developpeur.Rmd
Original file line number Diff line number Diff line change
Expand Up @@ -11,17 +11,17 @@ vignette: >
knitr::opts_chunk$set(echo = TRUE, eval = FALSE)
```

Ceci est un dossier de documentation dédié aux développeurs et développeuses. Il contient les choix de mode de développement et tout autre document qui ne s'adresserait pas directement aux utilisateurs.

Ceci est un dossier de documentation dédié aux développeurs et développeuses.

## Structuration du repo (a compléter)

Le développement de ce package a été réalisé avec {fusen} : les fonctions, vignettes et test sont générées par des fichiers Rmd dans le dossier /dev.
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.

Le repo contient deux app :
- une app de demo des composant de shinygouv : que l'on peut visualiser avec shinygouv::run_app(),
- une app de test pour la fonction de conversion convert_to_dsfr(), présente dans "inst/test.convert.dsfr/".


## Version du framework dsfr en cours de développement

Pour s'assurer du bon développement du package `shinygouv`, il a été ajouté au fichier `DESCRIPTION` la version du dsfr utilisé.
Expand All @@ -34,7 +34,7 @@ desc::desc_get("VersionDsfr")

## Ajouter une nouvelle version du dsfr

Si vous souhaitez implémenter une nouvelle version du dsfr, vous devez suivre les instructions disponible: [Montee en version du dsfr : trouver les fichiers CSS et JS](Dev-C-montee-en-version-du-dsfr-trouver-les-fichiers-css-et-js.md).
Si vous devez implémenter une nouvelle version du dsfr, vous devez suivre les instructions disponible: [Montee en version du dsfr : trouver les fichiers CSS et JS](Dev-C-montee-en-version-du-dsfr-trouver-les-fichiers-css-et-js.md).

Lorsque vous aurez implémenté toutes les composantes avec la nouvelle version, vous pourrez mettre à jour le fichier DESCRIPTION avec la commande suivante :

Expand All @@ -47,6 +47,7 @@ desc::desc_set("VersionDsfr" = "1.7.2")
- Notes de versions du dsfr https://www.systeme-de-design.gouv.fr/a-propos/versions/version-courante
- Notes de versions shiny : https://github.com/rstudio/shiny/blob/main/NEWS.md


## Workflow à suivre avant de dev sur le projet :

### Ajouter le template de commit :
Expand Down Expand Up @@ -101,7 +102,7 @@ chore : tout ce qui touche au projet en lui même, ne correspond pas à un feat

## Comprendre et appliquer le workflow pour développer le package

Pour développer ce package, des choix techniques ont été adoptés. Vous retrouverez les raisons [ici](Dev-F-documentation-inventaire.md).
Pour développer ce package, des choix techniques ont été adoptés. Vous retrouverez les raisons [ici](Hist-B-documentation-inventaire.md).

Le workflow se découpe en deux possibilités :

Expand All @@ -115,13 +116,24 @@ Ces deux possibilités se basent sur le même principe : **l'utilisation des tem
Vous trouverez des exemples pour d'autres composants :

- Avec réactivité:
- [radio buttons](../reference/radioButtons_dsfr.html)
- [radio buttons](https://github.com/spyrales/shinygouv/blob/main/dev/flat_composants/flat_radioButtons.Rmd)

- Sans réactivité:
- [Fluid page](../reference/fluidPage_dsfr.html)
- [Fluid page](https://github.com/spyrales/shinygouv/blob/main/dev/flat_composants/flat_fluidpage.Rmd)

N'hésitez pas à amender cette liste au fur et à mesure de vos développements

## Workflow avant de commit

Pensez à exécuter les lignes "Each time needed" du fichier [dev/02_dev.R](https://github.com/spyrales/shinygouv/blob/main/dev/02_dev.R) avant chaque commit.

```{r, eval=FALSE}
rstudioapi::navigateToFile("dev/02_dev.R")
```

<!-- ## Ressource JS, HTML et CSS : a compléter et lier au reste -->
<!-- https://connect.thinkr.fr/js4shinyfieldnotes/# -->

## Les langues utilisées dans le projet

- Rapports d'exploration (présentés en vignettes) : 🇫🇷
Expand All @@ -132,13 +144,3 @@ N'hésitez pas à amender cette liste au fur et à mesure de vos développements
- Description des tests unitaires (de préférence en anglais) 🇫🇷
- Code of Conduct: template par défaut de {usethis} en anglais déjà présent comme pour {gouvdown} 🇬🇧
- Contributing: template par défaut de {usethis} en anglais peut être ajouté comme pour {gouvdown} 🇬🇧

## Workflow avant de commit

Pensez à exécuter les lignes "Each time needed" du fichier [dev/02_dev.R](https://github.com/spyrales/shinygouv/blob/main/dev/02_dev.R) avant chaque commit.

```{r, eval=FALSE}
rstudioapi::navigateToFile("dev/02_dev.R")
```


10 changes: 6 additions & 4 deletions vignettes/Dev-B-comment-faire-un-composant-shiny.Rmd
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ shiny::actionButton("test", "test")
`<button id="test" type="button" class="btn btn-default action-button">test</button>`
```

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'évenement 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<HTMLElement> {
return $(scope).find(".action-button");
Expand Down Expand Up @@ -121,10 +121,12 @@ Ayez une attention particulière pour les tests unitaires qui sont la garantie d

#### Cinquième étape

Lorsque l'implementation de votre nouveau composant dsfr est terminée:
- remplir la table de correspondance disponible dans [inst/v1.9.3/table_correspondance_shiny_dsfr.csv](https://github.com/spyrales/shinygouv/blob/main/inst/v1.9.3/table_correspondance_shiny_dsfr.csv) (en adaptant sur la version en cours d'implementation)
Lorsque l’implémentation de votre nouveau composant dsfr est terminée :

- remplir la table de correspondance disponible dans [inst/v1.9.3/table_correspondance_shiny_dsfr.csv](https://github.com/spyrales/shinygouv/blob/main/inst/v1.9.3/table_correspondance_shiny_dsfr.csv) (en adaptant sur la version en cours d’implémentation)

La colonne `composant_shiny` restera vide si le composant dsfr n'a pas d'équivalent dans {shiny}.

La colonne `composant_shiny` restera vide si le composant dsfr n'a pas d'équivalent dans {shiny}.
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()`)


Original file line number Diff line number Diff line change
Expand Up @@ -24,11 +24,15 @@ library(shinygouv)
knitr::opts_chunk$set(eval = FALSE)
```

## Comment savoir ce qui a été mis à jour ?
# Comment savoir ce qui a été mis à jour ?

Le principe de ce package est de proposer une transposition des fonctions de {shiny} à la charte graphique Marque Etat grâce au [design system de l'Etat](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/. Pour savoir si une montée de version est nécessaire, consultez les notes de versions du dsfr sur https://www.systeme-de-design.gouv.fr/a-propos/versions/version-courante.

Egalement, les fonctions shiny transposées peuvent évoluer : consultez ici les notes de versions de shiny : https://github.com/rstudio/shiny/blob/main/NEWS.md.


# Procéder à une montée de version du dsfr

Dans le dossier "inst/" du package, nous allons créer deux dossiers:

- un pour récolter les css et js du dsfr,
Expand All @@ -43,7 +47,7 @@ Indiquez ici le numéro de la nouvelle version à implémenter que vous pourrez
nouvelle_version <- "1.9.3"
```

# Récolter les fichiers CSS et JS du DSFR
## Récolter les fichiers CSS et JS du DSFR

- Télécharger le zip de la dernière version `1.7.2` qui se trouve [ici](https://gouvfr.atlassian.net/wiki/spaces/DB/pages/223019574/D+veloppeurs)
- Décompresser le fichier
Expand Down Expand Up @@ -84,7 +88,7 @@ Vous pouvez lancer le contenu du script [dev/tools/maj_version_dsfr.R](https://g
On pourra ensuite créer une fonction qui permettera d'ajouter les dépendances dans les applications {shiny}.


## Mettre à jour les composants avec le nouveau dsfr
### Mettre à jour les composants avec le nouveau dsfr

Dans le fichier "table_correspondance_shiny_dsfr.csv", mettez `non` dans la colonne `mis_a_jour` car pour le moment, vous ne vous êtes pas assurer du bon foncionnement des composants dans la nouvelle version.

Expand All @@ -106,7 +110,7 @@ cat(
)
```

# Monter le numéro de version dans DESCRIPTION
## Monter le numéro de version dans DESCRIPTION

Quand tous les dossiers sont prêt, pour garder trace de la version du dsfr utilisée dans {shinygouv}, nous stockons celle en cours dans le fichier DESCRIPTION

Expand All @@ -115,7 +119,7 @@ Quand tous les dossiers sont prêt, pour garder trace de la version du dsfr util
desc::desc_set("VersionDsfr" = nouvelle_version)
```

# Nettoyer la version d'avant
## Nettoyer la version d'avant

Nous n'avons pas besoin de stocker toutes les versions du dsfr dans le package.
Maintenant que vous avez récupéré les fichiers pour une nouvelle version, vous pouvez supprimer la plus ancienne.
Expand All @@ -138,7 +142,7 @@ if (length(all_versions > 2)) {
}
```

# Récupérer les codes HTML un par un
## Récupérer les codes HTML un par un

Suivre la procédure de création de composant dans la vignette `Comment faire un composant shiny`

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,8 @@ knitr::opts_chunk$set(
library(shinygouv)
```

# Note sur les orientations initiales de développement : présentation des options

### 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)

Pour ce faire, nous avons rédigé un tableau comparatif entre les éléments trouvés dans le framework DSFR et {shiny}.
Expand Down Expand Up @@ -302,6 +304,6 @@ Les éléments tels que navbarpage, tabpanel etc sont possible dans la limite de

Nous préconisons l'**option D**. Pourquoi ?

Cette aprroche 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 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}.


Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,8 @@ library(shinygouv)
```


# Note sur les orientations initiales de développement : études des usages au ministère de l'Ecologie

Vous trouverez ci dessous les observations suite à un inventaire (non exhaustif) des outils de mises en pages ainsi que les différentes composantes, utilisées dans les applications shiny déployées sous https://ssm-ecologie.shinyapps.io


Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -11,6 +11,8 @@ vignette: >
knitr::opts_chunk$set(echo = TRUE, eval = FALSE)
```

# Note sur les orientations initiales de développement : comparaison avec {shiny.dsfr}

Le package {shiny.dsfr} disponible [ici](https://gitlab-forge.din.developpement-durable.gouv.fr/dreal-pdl/csd/shiny.dsfr/-/tree/main/) utilise {charpente} et reprend la structure "classique" d'un package qui implémente une nouvelle interface utilisateur.

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.
Expand Down

0 comments on commit d888a87

Please sign in to comment.