You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Web-Dev-For-Beginners/translations/fr/7-bank-project/4-state-management/assignment.md

155 lines
9.7 KiB

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Implémenter la boîte de dialogue "Ajouter une transaction"
## Vue d'ensemble
Votre application bancaire dispose désormais d'une gestion d'état solide et d'une persistance des données, mais il lui manque une fonctionnalité cruciale dont les vraies applications bancaires ont besoin : la possibilité pour les utilisateurs d'ajouter leurs propres transactions. Dans cette tâche, vous allez implémenter une boîte de dialogue complète "Ajouter une transaction" qui s'intègre parfaitement avec votre système de gestion d'état existant.
Cette tâche rassemble tout ce que vous avez appris dans les quatre leçons bancaires : le templating HTML, la gestion des formulaires, lintégration API et la gestion détat.
## Objectifs d'apprentissage
En complétant cette tâche, vous allez :
- **Créer** une interface de dialogue conviviale pour la saisie des données
- **Implémenter** une conception de formulaire accessible avec support clavier et lecteur d'écran
- **Intégrer** les nouvelles fonctionnalités avec votre système de gestion détat existant
- **Pratiquer** la communication API et la gestion des erreurs
- **Appliquer** des modèles modernes de développement web à une fonctionnalité réelle
## Instructions
### Étape 1 : Bouton Ajouter une transaction
**Créer** un bouton "Ajouter une transaction" sur votre page de tableau de bord que les utilisateurs peuvent facilement trouver et utiliser.
**Exigences :**
- **Placer** le bouton à un emplacement logique sur le tableau de bord
- **Utiliser** un texte clair et orienté action pour le bouton
- **Styliser** le bouton pour quil corresponde à votre design UI existant
- **Assurer** que le bouton soit accessible au clavier
### Étape 2 : Implémentation de la boîte de dialogue
Choisissez lune de ces deux approches pour implémenter votre boîte de dialogue :
**Option A : Page séparée**
- **Créer** un nouveau template HTML pour le formulaire de transaction
- **Ajouter** une nouvelle route dans votre système de routage
- **Implémenter** la navigation vers et depuis la page du formulaire
**Option B : Boîte de dialogue modale (recommandé)**
- **Utiliser** JavaScript pour afficher/masquer la boîte de dialogue sans quitter le tableau de bord
- **Implémenter** en utilisant la [propriété `hidden`](https://developer.mozilla.org/docs/Web/HTML/Global_attributes/hidden) ou des classes CSS
- **Créer** une expérience utilisateur fluide avec une gestion correcte du focus
### Étape 3 : Implémentation de l'accessibilité
**Assurer** que votre boîte de dialogue respecte les [normes d'accessibilité pour les dialogues modaux](https://developer.paciellogroup.com/blog/2018/06/the-current-state-of-modal-dialog-accessibility/) :
**Navigation clavier :**
- **Supporter** la touche Échap pour fermer la boîte de dialogue
- **Piéger** le focus à lintérieur de la boîte de dialogue lorsquelle est ouverte
- **Restaurer** le focus sur le bouton déclencheur lors de la fermeture
**Support lecteur décran :**
- **Ajouter** des labels et rôles ARIA appropriés
- **Annoncer** louverture/fermeture de la boîte de dialogue aux lecteurs décran
- **Fournir** des étiquettes claires pour les champs de formulaire et les messages derreur
### Étape 4 : Création du formulaire
**Concevoir** un formulaire HTML qui collecte les données de transaction :
**Champs requis :**
- **Date** : Quand la transaction a eu lieu
- **Description** : À quoi correspond la transaction
- **Montant** : Valeur de la transaction (positive pour revenu, négative pour dépense)
**Fonctionnalités du formulaire :**
- **Valider** les entrées utilisateur avant la soumission
- **Fournir** des messages derreur clairs pour les données invalides
- **Inclure** des textes indicatifs et des étiquettes utiles
- **Styliser** de manière cohérente avec votre design existant
### Étape 5 : Intégration API
**Connecter** votre formulaire à lAPI backend :
**Étapes dimplémentation :**
- **Consulter** les [spécifications de lAPI serveur](../api/README.md) pour lendpoint et le format des données corrects
- **Créer** des données JSON à partir des entrées du formulaire
- **Envoyer** les données à lAPI avec gestion derreurs appropriée
- **Afficher** des messages de succès/échec à lutilisateur
- **Gérer** proprement les erreurs réseau
### Étape 6 : Intégration avec la gestion détat
**Mettre à jour** votre tableau de bord avec la nouvelle transaction :
**Exigences dintégration :**
- **Actualiser** les données du compte après lajout réussi de la transaction
- **Mettre à jour** laffichage du tableau de bord sans recharger la page
- **Faire apparaître** immédiatement la nouvelle transaction
- **Maintenir** la cohérence de létat tout au long du processus
## Spécifications techniques
**Détails de lendpoint API :**
Référez-vous à la [documentation API serveur](../api/README.md) pour :
- Le format JSON requis pour les données de transaction
- La méthode HTTP et lURL de lendpoint
- Le format de la réponse attendue
- La gestion des réponses derreur
**Résultat attendu :**
Après avoir réalisé cette tâche, votre application bancaire doit disposer dune fonctionnalité "Ajouter une transaction" complètement fonctionnelle, professionnelle en apparence et en comportement :
![Capture d'écran montrant un exemple de boîte de dialogue "Ajouter une transaction"](../../../../translated_images/fr/dialog.93bba104afeb79f1.webp)
## Tester votre implémentation
**Tests fonctionnels :**
1. **Vérifier** que le bouton "Ajouter une transaction" est clairement visible et accessible
2. **Tester** louverture et la fermeture correcte de la boîte de dialogue
3. **Confirmer** que la validation du formulaire fonctionne pour tous les champs requis
4. **Vérifier** que les transactions réussies apparaissent immédiatement sur le tableau de bord
5. **Sassurer** que la gestion des erreurs fonctionne pour les données invalides et les problèmes réseau
**Tests daccessibilité :**
1. **Naviguer** dans tout le processus uniquement au clavier
2. **Tester** avec un lecteur décran pour assurer une annonce correcte
3. **Vérifier** que la gestion du focus fonctionne correctement
4. **Contrôler** que tous les éléments du formulaire ont des étiquettes appropriées
## Grille dévaluation
| Critères | Exemplaire | Adéquat | À améliorer |
| -------- | ---------- | ------- | ----------- |
| **Fonctionnalité** | La fonction dajout de transaction fonctionne parfaitement avec une excellente expérience utilisateur et suit toutes les bonnes pratiques des leçons | La fonction dajout de transaction fonctionne correctement mais peut ne pas suivre certaines bonnes pratiques ou comporter de petits problèmes dutilisabilité | La fonction dajout de transaction est partiellement fonctionnelle ou présente des problèmes importants dutilisabilité |
| **Qualité du code** | Le code est bien organisé, suit les modèles établis, inclut une bonne gestion des erreurs et sintègre parfaitement avec la gestion détat existante | Le code fonctionne mais peut avoir des problèmes dorganisation ou des modèles incohérents par rapport au code existant | Le code présente des problèmes structurels importants ou ne sintègre pas bien avec les modèles existants |
| **Accessibilité** | Support complet de la navigation au clavier, compatibilité avec les lecteurs décran, et respect des directives WCAG avec une excellente gestion du focus | Fonctionnalités daccessibilité de base implémentées mais peut manquer certaines options de navigation au clavier ou de support lecteur décran | Considérations daccessibilité limitées ou inexistantes |
| **Expérience utilisateur** | Interface intuitive, soignée avec des retours clairs, des interactions fluides et une apparence professionnelle | Bonne expérience utilisateur avec quelques points à améliorer en termes de retour utilisateur ou design visuel | Mauvaise expérience utilisateur avec une interface confuse ou un manque de retours utilisateur |
## Défis supplémentaires (optionnel)
Une fois les exigences de base complétées, vous pouvez envisager ces améliorations :
**Fonctionnalités avancées :**
- **Ajouter** des catégories de transaction (alimentation, transports, loisirs, etc.)
- **Implémenter** une validation des entrées avec retour en temps réel
- **Créer** des raccourcis clavier pour les utilisateurs avancés
- **Ajouter** des fonctionnalités dédition et de suppression de transactions
**Intégration avancée :**
- **Implémenter** une fonction dannulation pour les transactions récemment ajoutées
- **Ajouter** limportation massive de transactions depuis des fichiers CSV
- **Créer** des fonctionnalités de recherche et filtrage de transactions
- **Implémenter** lexport des données
Ces fonctionnalités optionnelles vous aideront à approfondir vos connaissances en développement web avancé et à créer une application bancaire plus complète !
---
<!-- CO-OP TRANSLATOR DISCLAIMER START -->
**Avertissement** :
Ce document a été traduit à laide du service de traduction automatique [Co-op Translator](https://github.com/Azure/co-op-translator). Bien que nous nous efforcions dassurer lexactitude, veuillez noter que les traductions automatiques peuvent contenir des erreurs ou des inexactitudes. Le document original dans sa langue dorigine doit être considéré comme la source faisant autorité. Pour les informations critiques, il est recommandé de recourir à une traduction professionnelle réalisée par un humain. Nous ne saurions être tenus responsables de toute mauvaise compréhension ou interprétation résultant de lutilisation de cette traduction.
<!-- CO-OP TRANSLATOR DISCLAIMER END -->