Temps passé par un bénéfiaire d'un service #23
+10,210
−938
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ggounot
changed the title
Added a nnew section "Beneficiary participation" with spending_time_* fields (total hours and operating details) Needed to enrich / fix the basic-input-field component in order to correctly support numeric value. In order to do this, we needed to add type `number` to variable `value`. Thus, we had to force `value.toString()` in some places in the component. Not very satisfying, but I did not have clever idea.
* Add testing-library framework for Svelte (with jsdom) * Fix TypeScript config * Add an example of component testing with BasicInputField Good-to-konw: In order to render, <BasicInputField/> requires that the given ID to be included (defined) in the associated form schema. It is why the tests use `spendingTimeTotalHours`. This mechanism is based on a Svelte $store object (so the '$' character in the template). I thought I had to defined "context" (in `render()` method) but they are two separate concepts. The solution was simplest, just importing and changing value of the form schema.
It seems that there is a well known problem since few months, see vitejs/vite#15532 Lots of people recommend to add this optional dependency. Don't understand where, when and by whom it is required in the project.
Added .history to both .gitignore and .eslintignore to prevent temporary files created by the VSCode extension from being tracked by Git or linted by ESLint.
jbuget
force-pushed
the
feat/temps-passe-par-service
branch
from
dcf448c
to
6e11310
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ℹ️ PR créée à partir des PR originales gip-inclusion/dora-back#369 et gip-inclusion/dora-front#446 suite à la création du monorepo.
Backend
🍣 Problème
En tant que Éditeur d’un Service pour ma Structure, je souhaite indiquer, pour le-dit service, le temps passé (en nombre d'heures totales, avec une éventuelle précision sur la répartition) par le Bénéficiaire afin d’aider à l’orientation d’un service par les Accompagnateurs tout en satisfaisant aux obligations légales à venir (loi Travail 2025).
🦄 Solution
Ajouter 1 section ("Participation du bénéficiaire") avec 2 champs dans le formulaire d'édition d'une structure :
✅ Pour tester
🍀 Misc
Frontend
🍣 Problème
Il s'agit de la partie front de gip-inclusion/dora-back#369
🦄 Solution
On ajoute une section dans le formulaire d'édition d'un service.
Cette nouvelle section permet de définir 2 champs :
Côté implémentation, on utilise, modifie et enrichit le composant
<BasicInputField/>pour qu'il supporte correctement le type "number".Jusqu'à présent, on l'utilisait avec des types ["text", "tel", "email"] tous basés sur une valeur de type String. Il a fallu l'adapter pour supporter aussi le type
Number. Conséquence : nécessite quelques.toString()à certains endroits.Sur le modèle du type "tel", il a fallu définir des handlers spécifiques pour s'assurer que le format Number reste valide.
Côté utilisateur, on empêche l'utilisateur de saisir autre chose que des chiffres. On fait en sorte qu'il puisse quand même effacer la valeur et enregistrer (sans erreur) le formulaire.
🍒 Bonus
1/ Test de composants
Cette PR ajoute le support de tests de composant (rendu et comportement).
Pour cela on ajoute la bibliothèque Testing Library, compatible et préconisée avec Svelte(kit) / Vitest.
Les plus grosses difficultés rencontrées :
2/ Vite UI
Par ailleurs, cette PR permet aussi de lancer les tests via l'éditeur graphique.
Cela se fait avec la commande :
npm run test:uiAucune difficulté ni rien de notable (à part que c'est assez cool).
3/ Ignore le répertoire .history
Il s'agit d'un répertoire utilisé par certaines extensions d'IDE (comme VSCode).
Par souci de se prémunir d'ajout intempestif qui pourrait perturber Git ou ESLint, on les ajoute aux fichiers à ignorer (
.gitignoreet.eslintignore).4/ Stabiliser la CI
J'ai rencontré un souci récurrent de CI, peut-être parce que je suis sous Mac (mais pas sûr). Apparemment, il s'agit d'un problème connu de Vite depuis des mois, cf. cette issue GitHub.
La solution proposée par de multiples contributeur a fonctionné pour moi. Je propose de la conserver sur le projet.
👓 Revue de code
On peut y aller commit-par-commit 🧘♂️.