Il y a besoin d'installer le frontend et le backend pour profiter de l'expérience complÚte de développement. Voir le readme du backend pour le faire tourner.
git clone git@github.com:david-bretaud-dev/pims-frontend.gitLe gestionnaire de package utilisé dans ce readme sera npm.
Installer les packages avec la commande suivante :
npm installLe script "postinstall": "copy-dsfr-to-public" (cf package.json) fait une copie de dsfr dans le dossier public. Il ne faut pas y toucher, car c'est là que tout le css du DSFR est stocké.
Ce css est chargé dans le composant DSFRWrapper, avec la balise suivante : <link rel="stylesheet" href="/dsfr/dsfr.min.css" />.
Pour faire tourner l'application en local :
npm run devL'application tournera sur l'url localhost:5173.
Pour créer un build de l'application, et vérifier que le code est fonctionnel :
npm run buildLe bundle est généré dans le dossier ./dist.
Pour utiliser le build pour faire tourner l'application en local :
npm run previewPlus de dĂ©tails sur la partie Widget peuvent ĂȘtre trouvĂ©es dans la suite de ce README. Pour faire bref, l'application peut ĂȘtre importĂ©e comme un Web Component dans n'importe quelle page html.
Un exemple est disponible Ă cet url.
Cette intĂ©gration Widget peut ĂȘtre testĂ©e avec le build local (port 4173). Pour ce faire, il suffit d'utiliser de crĂ©er un fichier html comme suit :
<html>
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Client website</title>
<script
src="http://localhost:4173/assets/js/widget.js"
type="module"
></script>
</head>
<body>
<pims-dematerialized-widget></pims-dematerialized-widget>
<h1>Hello</h1>
</body>
</html>Le PIMS dĂ©matĂ©rialisĂ© a pour objectif d'ĂȘtre une tĂ©lĂ©-procĂ©dure d'Etat. A cet effet, elle doit respecter diffĂ©rentes contraintes.
Le DSFR est le Design System de l'Ătat français. C'est un ensemble de rĂšgles Ă respecter, de composants Ă utiliser, de typographies Ă utiliser (Marianne, Spectral), de couleurs Ă utiliser selon des rĂšgles strictes.
Le DSFR existe donc sous la forme d'une librairie javascript, permettant d'avoir facilement ces différentes rÚgles d'implémenter (typographies, thÚme de couleur, composants réutilisables). Pour construire l'application, il "suffit" de respecter les rÚgles d'utilisations du DSFR.
RĂšgles d'utilisation du Stepper du DSFR
Lâindicateur d'Ă©tapes ne sert pas Ă naviguer dâune Ă©tape Ă lâautre, pour cela utiliser des boutons en bas des champs de l'Ă©tape. Il est conseillĂ© de finir par une Ă©tape de confirmation. Il est aussi conseillĂ© de crĂ©er une page dâintroduction Ă la dĂ©marche, avant de commencer cette derniĂšre pour prĂ©senter les diffĂ©rentes Ă©tapes, sur laquelle ne figure pas cet indicateur dâĂ©tapes.
A cet effet :
- le composant
./src/layouts/components/stepper/Stepper.tsxne permet pas de naviguer ; - le composant
./src/layouts/components/Navigator.tsxpermet de faire cette navigation ; - la navigation est précédée d'une page d'introduction
./src/lib/0-home/HomeScreen.tsxprésentant les différentes étapes.
Pour développer une application React, on utilise à la place la librairie React DSFR, qui reprend (quasiment) tous les composants du DSFR original.
Lorsque cette librairie est installée, de nombreux fichiers sont créés dans le dossier ./public/dsfr (ils ne sont donc pas traités par le Build de Vite). Parmi ces fichiers se trouvent tous les composants nécessaires, le css et les polices (Marianne, Spectral) du DSFR, il n'y a donc pas besoin de les gérer de notre cÎté.
- RGPD
- Checklist Pidila
L'application est pour le moment disponible en français (fr) et en anglais (en). L'internationalization est gérée avec react-i18next, et dans le dossier ./src/i18n.
Le fichier i18n génÚre l'object i18n utilisé ensuite dans App.tsx pour générer le I18nProvider.
Le dossier translations contient les fichiers de traduction, 1 par language, nommés avec la forme [locale].json.
Comme l'application est 100% cĂŽtĂ© Client, la mĂ©thode est toujours la mĂȘme pour utiliser des traductions. Elle repose sur le hook useTranslation. Les clĂ©s de traductions sont toutes Ă©crites en snake_case.
import { useTranslation } from 'react-i18next';
export default function MyFunctionalComponent() {
const { t } = useTranslation('namespace');
const myTranslation = t('key_translation.to_my.sentence');
}Plusieurs APIs sont utilisées pour récupérer automatiquement différentes données.
Cette API nous permet de :
- Autocompléter le nom de l'adresse entré dans l'Input d'adresse
- Récupérer des informations complÚtes sur la position de l'utilisateur : adresse, coordonnées latitude & longitude, code Insee.
Liens utiles :
Cette API nous permet de récupérer les risques autour d'une position donnée (par adresse ou par coordonnées).
Liens utiles :
Cette API nous permet de rĂ©cupĂ©rer le numĂ©ro de tĂ©lĂ©phone de la mairie de la ville oĂč se trouve l'utilisateur, Ă partir du code Insee celle-ci.
Liens utiles :
- Informations sur l'API
- Site internet et simulateur de l'API
- Document pdf à destination des développeurs pour comprendre comment utiliser l'API
- Tutoriel plus technique pour utiliser l'API
Un Proxy a été développé pour récupérer, à partir d'un jeu de coordonnées latitude & longitude, les fréquences Radio france. Comme il n'y a pas d'API radio france permettant de récupérer ces données, le proxy a pour seul objectif de récupérer un contenu html rendu sur cette page : https://www.radiofrance.com/frequences. L'utilisation d'un proxy a été rendue nécessaire à cause de problÚmes CORS.
Le contenu html est ensuite parsé pour extraire les données souhaitées.
Ce proxy est codé sur le repository pims-proxy et déployé à l'url https://pims-proxy.vercel.app.
Une des ambitions du PIMS dĂ©matĂ©rialisĂ© est de le gĂ©nĂ©raliser dans la vie professionnelle et associative. Un levier pour cela est d'avoir l'application qui gĂ©nĂšre le PIMS intĂ©grĂ©e dans le site des associations ou entreprises, afin que celles-ci offrent un rĂ©fĂ©rentiel Ă leurs employĂ©s sur oĂč aller chercher la ressource.
L'application pims-frontend a donc Ă©tĂ© pensĂ©e et conçue pour ĂȘtre un site mais aussi un Web component intĂ©grable dans n'importe quel autre site (cf Tester le widget).
Pour ce faire :
- le fichier
./src/widget.tsxutiliser2wcpour transformer l'application React en Web Component. - pour des Ă©volutions potentielles, oĂč le widget devrait se distinguer du site gouvernemental, un exemple est fait avec le
Header. - le composant
DSFRWrapperpermet d'injecter dans le head du site hébergeur les scripts nécessaires pour utiliser le DSFR. - le build de l'application par Vite, dont la stratégie se retrouve dans
vite.config.ts, permet de générer dans le bundle un scriptwidget.jsqui exporte le Web component de./src/widget.tsxaprÚs y avoir injecté le css. C'est ce script qui est récupéré lors de l'incorporation Widget sur un site externe (cf Tester le widget)
Le build de l'application par Vite suit la configuration du fichier vite.config.ts. Celle-ci a Ă©tĂ© faite de sorte Ă avoir un build simple, oĂč le css est injectĂ© dans une page js principale, et oĂč les assets sont bien hashĂ©s et ordonnĂ©s.
La librairie cssInjectedByJsPlugin permet de rĂ©cupĂ©rer tous les fichiers css, de les agrĂ©ger ensemble, et d'injecter le css final dans les fichiers javascripts "spĂ©cifiĂ©s". Ces fichiers sont ceux qui vĂ©rifient la condition de sortie de la fonction jsAssetsFilterFunction. Dans notre cas, le css doit ĂȘtre injectĂ© Ă la fois dans le fichier unique js qui fait tourner le site (assets/main.js), mais aussi dans le fichier qui contient le widget (le Web component a besoin du css aussi!)(assets/js/widget.js).
Plusieurs sources de css :
- le css de react-dsfr, copié dans dist/dsfr
- le css custom de notre repo
| Env | CSS custom | CSS DSFR |
|---|---|---|
| localhost:5173 | Imported in main.tsx |
|
| build | Injected in assets/main.js |
Injected from the build cdn |
| widget | Injected in assets/js/widget.js |
Injected from the build cdn |
Une documentation explicite les différents items : https://rollupjs.org/configuration-options/.
input : En spécifiant une map, qui relie un nom à un entry point / fichier, les entry points seront séparés dans plusieurs chunks. En spécifiant à la fois main et widget, on s'assure d'avoir deux chunks séparés pour les deux applications.
output.entryFileNames : pour le chunk qui porte le nom widget, nous le plaçons dans le dossier assets/js, et tous les autres iront dans le dossier assets.
output.assetFileNames: on organise de mĂȘme les fichiers considĂ©rĂ©s comme assets statiques par Vite : ce sont des images, des svg, Ă partir d'une certaille, et qui ont besoin d'ĂȘtre optimisĂ©es. En bref, les images sont mis dans le dossier assets/images, les medias dans le dossier assets/medias, et le reste sera placĂ© dans assets. Leurs URLs sont gĂ©rĂ©s par Vite.
Les trĂšs petites images (<=4kb / 4096 bytes) sont encodĂ©es en base64 data URIs. Cela permet d'amĂ©liorer les performances en Ă©vitant des requĂȘtes HTTP supplĂ©mentaires.
Le script de build fait automatiquement une copie de public/dsfr vers dist/dsfr.
- DSFR
- DSFR - Prise en main pour les développeurs
- DSFR - IcĂŽnes
- React DSFR
- React DSFR - Components documentation
- React DSFR - Github
- Exemple de projets utilisant React DSFR
- react-i18next
- Le tutoriel qui a inspiré la configuration du Widget en Web component
- API Annuaire administration
- Vite React
- Vite Build rollup options