[explo-processus] Indiquer ce que serait la méthode de mise à jour avec la méthode {charpente}

[statnmap]

ETQ futur mainteneurs et utilisateurs, je souhaite savoir ce que cela implique d'intégrer une mise à jour esthétique du DSE dans une app shiny existante si la méthode est {charpente}, afin de choisir la méthode adaptée

Critères d'acceptation

• Je sais pourquoi nous n'avons pas directement retenu la méthode {charpente}:
  Utiliser {charpente} implique de recoder la partie HTML d'une composante avec les fonctions de {shiny} type tags$p(), tags$a(), ...
  Or, le DSFR fournit le code HTML brut, que l'on peut copier en l'état depuis le sources du DSFR dans un htmlTemplate() sans que cela ne réduise les possibilité de modification des composantes.
  Ainsi, sans repasser pas {charpente}, nous simplifions l'ajout et la maintenance des composants.

Un rapport / vignette avec :

• La présentation de deux composantes shiny existantes, une simple et une plus complexe (cf. le tableau de Exploration du processus de mise à jour)

  • Choisir les mêmes que [explo-processus] Indiquer ce que serait la méthode de mise à jour avec {bslib} #8 si possible

• ETQ mainteneur, Je sais comment créer et modifier les composantes sur-mesure et intégrer les nouveaux CSS/JS fournis par le DSE dans mon package pour l'option C:
  https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#option-c-from-scratch

• ETQ mainteneur, Je sais la complexité de modifier automatiquement ces composantes dans le package {shinygouv} avec un code R (pas forcément à développer dès maintenant) pour le jour où les fichiers sources sont mis à jour côté DSE pour l'option C
  

• ETQ utilisateur, Je sais la complexité de passer le template d'une application Shiny déjà en production vers l'utilisation de {shinygouv} pour l'option C (même capture qu'au-dessus)
  

• ETQ mainteneur, Je sais comment créer et modifier les composantes sur-mesure et intégrer les nouveaux CSS/JS fournis par le DSE dans mon package pour l'option D:
  https://spyrales.github.io/shinygouv/articles/recommandation-pour-l-implementation-de-dsfr.html#option-d-from-scratch-mais-pas-vraiement

• ETQ mainteneur, Je sais la complexité de modifier automatiquement ces composantes dans le package {shinygouv} avec un code R (pas forcément à développer dès maintenant) pour le jour où les fichiers sources sont mis à jour côté DSE pour l'option D
  

• ETQ utilisateur, Je sais la complexité de passer le template d'une application Shiny déjà en production vers l'utilisation de {shinygouv} pour l'option D (même capture qu'au-dessus)
  

Comment technique

• Définir comment pourraient être créé les HTML sur-mesure des composantes, et intégrer le CSS du DSE
• Indiquer comment ce serait utliisé avec {charpente} pour être appliqué à une Shiny existante
• Ecrire en toutes lettres, les étapes à réaliser pour la transformation d'une application Shiny existante déjà en prod
• Ecrire en toutes lettres, les étapes à réaliser pour mettre à jour le package si le DSE change (nouvelles polices, nouvelles couleurs, nouveau logos, ...)

=> Ces informations permettront aux commanditaires de choisir la méthode adaptée à leur besoin et leurs critères de succès à savoir

• Eviter d'avoir des fonctions spécifiques pour ne pas gêner le passage d'un template à un autre si possible
• Le package doit être maintenable par les utilisateurs et peut être mis à jour rapidement s'il y a des mises à jour des fichiers css/js/polices/images du côté Design System de l'Etat

[jengelaere]

Vraiment besoin de m'attarder sur l'option C qui n'a pas été retenue ?
Sur l'option D, je ne coche pas 'ETQ mainteneur, Je sais comment créer et modifier les composantes sur-mesure et intégrer les nouveaux CSS/JS fournis par le DSE dans mon package pour l'option D'
J'ai bien lu la doc, mais elle n'est pas suffisante pour moi, je dois avoir trop de lacune sur html, css et js.

[statnmap]

Ajout d'info avec le #58
Validé en réunion du 2022-09-07