-
Notifications
You must be signed in to change notification settings - Fork 2
Implémentation
[Explication des conventions de codage, description des outils de "linting" et de tout ce qui a été mis en place pour s'assurer de la qualité du code produit.]
Les fichiers de composant ou de page (JS) sont placés dans des dossiers représentants leurs catégories. Par exemple il y a un dossier connection qui contient:
- un fichier js qui est la page de connection/inscription (
conreg.js), - deux fichiers de type "composant" qui sont le composant connection (
connexion.js) et le composant d'inscription (register.js).
On vaillera donc à respecter cette convention lors de la création d'autres pages comme dans l'exemple suivant:
Est-ce que la catégorie de la page que je vais créer est déjà représentée par un dossier ?
=> Si oui, je créer mes fichier js dans ce dernier
=> Si non, je créer un nouveau dossier représentant la catégorie de ma page et j'y place mes fichier js.
Les fichiers sont construit d'une manière très précise. En effet, vu que nous utilisons React et StyledComponents, l'allure du code est un peu spécifique.
Quand nous créons un fichier, nous essayons de suivre la structure suivante:
- 1: La déclaration de toutes les dépendances utilisé par le fichier,
- 2: Les Hooks et tous autres constantes ou fonctions,
- 3: Le return de la fonction du composant contenant la structure à proprement dite de la page,
- 4: Le css de chaque balise de la strucutre du composant définit avec StyledComponents,
- 5: Éventuellement, si le composant utilise Axios pour faire des requêtes backend, nous mettons les fonctions qui permettent de faire les liaisons avec les fichiers d'action (les "connetors"),
- 6: Dernièrement, l'export de la fonction principale du composant.
Les fichiers d'action sont nommés de manière claire pour que l'on puisse directement comprendre quel est leur utilisation. Par exemple, carAction.js, orderAction.js, userAction.js, etc (définition des noms en lowerCamelCase). Ces fichiers contiennent donc des fonctions qui utilisent Axios pour faire différents types de requêtes vers le backend. carAction contiendra donc toutes les requêtes Axios concernant les voitures (ajout de voitures, récupération des voitures, etc).
Il faut également vailler à définir chaque requête dans le fichier actionTypes.js.
Dans notre projet, StyledComponents est utilisé pour facilité la création et l'utilisation du CSS pour chaque composant créé. Quand une nouvelle balise StyledComponent est créée il faut la nommer en CamelCase.
StyledComponents doit être utilisé pour augmenter la compréhension du code, il n'est cependant pas recommendé de l'utiliser tous le temps.
En effet, dans notre code, on peut observer des endroits avec des simples balises <p> ou des <input>, en effet, ces balises sont assez explicites et on a donc pas vraiment d'utilité à utiliser StyledComponents.
Par contre, on peut remplacer les traditionnels imbrications de <div> par quelque chose de bcp plus compréhensible et lisible pour le développeur.
Exemple:
Ce code,
<div className="container">
<Header/>
<div className="content">
{!connexion
? <Register onSwap={toggle}/>
: <Connexion onSwap={toggle}/>}
</div>
</div>
devient ceci avec StyledComponent:
<Container>
<Header />
<Content>
{!connexion
? <Register onSwap={toggle}/>
: <Connexion onSwap={toggle}/>}
</Content>
</Container>
Les controllers sont des fichiers permettant d'effectuer des actions avec la base de données. Ces fichiers js suivent une convention de nommage simple mais efficace. Par exemple le fichier qui contient toutes les requêtes relatives au voitures est nommé "car.js". Chaque requête est donc placée dans le fichier qui correspond à sont utilisation (récupérer la liste des voitures => car.js, ajouter un user => user.js, etc).
Lors de la rédaction de requêtes dans un fichier controller il faut veiller à:
- Bien nommer sa requête, c'est à dire que sont nom soit cohérent avec sont utilisation,
- Utiliser les
tryet lescatch (error) {}pour définir la réaction lorsqu'une requête ne passe pas, - Toujours return quelque chose pour chaque fontion.
Des images peuvent être trouvées à deux endroits différents dans notre projet:
- Dans le dossier
backend/images, - Dans le dossier
frontend/public/images.
Dans le fichier backend/images, nous viendrons mettre toutes les images des voitures, des cartes d'identitées, etc.
En bref toutes les images qui sont "éphémères" et donc suceptibles d'être supprimées lors de la suppression d'une voiture par exemple. Ces images sont donc automatiquement créées par le code.
Ensuite, dans le fichier frontend/public/images, il faut placer toutes les images utilisées par le code comme les images de background ou les logos.
Ces images ne doivent pas être supprimées car elle sont indispensable à l'aspect visuel du site. Contrairement aux images du bakcend, elles sont créées par le développeur lors de la création d'une page.
Le camelCase est principalement utilisé pour les variables niveau frontend et backend car le language utilisé est le javascript.source . A certains endroit on peut retrouver du snace_case qui sont les noms des colonnes de la base de donnée.
Nous essayons pour d'attribuer à chaque variable un nom qui la décrit au mieux comme dans cette exemple où startDate représente la date de début de location d'une voiture
Afin de faciliter la compréhension du code des commentaires sont aussi mis en place pour chaque bout de code qui nécessite un peu de réflexion mais aussi des commentaires qui décrivent ce que fait chaque fonction dans le code
Nous essayons de respecter des conventions déjà établies en scindant le code dans des dossiers qui décrivent au mieux les tâches éffectuées.
Une aérationnous permet de nous retrouver facilement dans les 02 parties du projet frontend et backend et permet une meilleur lisibilité du code du code.
Un niveau d'imbrication de 4 espaces configuré grâce à l'extension prettier nous permet d'accroître énormement la lisibilité
[Descriptions des fonctionnalités réalisées aux différentes étapes du projet (ex : MVP, sprint 1, ...), type "release notes"]
Dans notre projet, nous avons suivi les diverses étapes pour la réalisation de notre site qui sont les suivantes:
Pour le MVP, nous avons utilisé le site mockplus (qui est un outil de création collaborative, prototype ...). Ce site nous a servi pour la réalisation de notre maquette et trouver également la conception de la façon dont nous espérons voir notre site. Nous avons commencé à réaliser les maquettes pour tous les US avant de nous lancer dans le développement.
Dans notre onglet "Accueil" l'utilisateur ou visiteur de notre site peut voir tout les informations concernant notre site ainsi que son utilisation
Il a été implémenté et testé
La fonctionnalité ajouter les voitures vise normalement l'administrateur qui sera à lui d'ajouter la voiture dans sa base de donnée. La fonctionnalité a déjà été implémenter sous forme où l'administrateur peut ajouter une voiture avec sa marque et son modèle
Il a été implémenté et testé
Cette fonctionnalité est seulement accessible si l'utilisateur est un administrateur qui aura la permission de retirer la voiture qui n'est pas disponible.
Il a été implémenté et testé
Lors de l’arrivé de l’utilisateur( inscris ou non inscris) sur la page d'accueil du site, il aura un formulaire avec des champs pour la date et l'heure de début de réservation ainsi que pour la date et l'heure de fin de réservation. Après complétion de ce formulaire, l'utilisateur est redirigé vers la page /cars ou il aura la liste des voitures triée en fonction des dates entré.
À l'arrivée de l'utilisateur dans l'onglet « Voitures »,il rencontrera un formulaire qui contient différents champs dont la marque et le modèle qui lui permettront de choisir sa marque qu'il souhaite louer.
[Explications de l'évolution éventuelle des choix de conception au cours du projet. Par ex : Changement d'architecture, modification de certains choix technologiques, refactoring approfondi, ... ]
Du côté backend, depuis le début nous somme basé sur le modèle Contrôleurs-Route-Middleware et le frontend se charge de contacter notre API est de faire le rendue. Un certain moment nous avons dû effectuer quelque vérification cote serveur, ceci nous a amenés à rajouter le dossier Validation qui contient les différents schémas des données reçu du front avant de les traités du côté back. Par la suite ont a décidé de travailler avec un ORM (Object–relational mapping) même celui-ci réduit les performances mais il a pas mal d'avantage (sécurité et bonne gestion des données). Actuellement voici l'architecture coté backend : Controller-database-images-middleware-routes-validations.
- Stockage des voitures au niveau du frontend
Au niveau de l'issue 1, lors de l'affichage des voitures au niveau du frontend, il est nécessaire de stocker les voitures dans un objet javascript mais avec le framework redux, le stockage de l'état ne doit pas être sous forme de tableau car celà augmente les disfonctionnements au niveau de l'état des composants réact.
- Connexion et inscription via google
Le système d'inscription et connexion simple fonctionne correctement mais l'implémentation via oauth n'est pas encore correctement terminé. La récupération des informations personnelles des utilisateurs via google s'effectue correctement mais Le stockage de ces informations dans la DB n'est pas encore au point mais.
- Réservation de voiture
Au niveau de l'issue 5, la réservation d'une voiture passe par une sélection de la plage horaire mais lors de l'insertion d'une plage horaire dans la base de données la conversion en en UTC implique un décalage de 2heures ce qui provoque l'insertion d'une date incorrecte dans la DB.
POURBAIX Michaël: US02 - Ajouter des véhicules
À tester.
L'ajout de voiture est implémenté et fonctionnel. En effet la page add-cars permet à l'administrateur de préciser, via un formulaire, toutes les caractéristiques de la nouvelle voiture et de l'ajouter à la base de données. Il puet également ajouter le nombre d'images qu'il souhaite pour cette voiture.'
- La plupart des fonctionnalités demandées sont présentes
- Ajout d'un pop-up afin d'informer l'administrateur que la voiture à bien été ajoutée (retour utilisateur)
- Possibilité d'ajouter plusieurs images pour la voiture et d'en retirer
- Vérification des valeurs des champs avant l'envoi du formulaire
- Quelques réglages CSS avec le pop-up
- Possibilité d'ajouter des vidéos
Abderrachid BELLAALI: US01 - Afficher les voitures
À tester.
L'affichage des voitures est implémenté et fonctionnel. La page Cars liste toutes les voitures disponibles. Celle-ci les affiches avec leur titre, caractéristique technique et les images correspondant à chacune.
- Sur la même page le client a un résumé de toutes les voitures qui corresponde à ce qui lui intéresse, il pourrait savoir directement si celle-ci luit plaît ou non sans à cliquer sur chacune et y passer du temps.
- Quelques réglages CSS
- Responsive
CARDIN Patson: US05 - Choisir la plage horaire de location
In progress.
- Une système de calendrier à déjà été mise en place au niveau de la page d'acceuil et de la barre des filtres dans la page d'affichage de voiture.
- L'utilisateur peut déjà choisir un plage horaire de location
- Cette sélection récupère bien les voitures disponibles à cet intervalle précis
- L'affichage des voitures filtrées est en cours de réalisation.
- Mettre en place le style et les conditions nécessaire au bon fonctionnement du calendrier effectué avec react-date
- La logique à mettre en place pour filtrer les voitures diponibles dans l'intervalle choisis par le visiteur/utilisateur
- L'adaptation du fuseau horaire selon votre localisation. Mise en place grâce à la librairie moment js
- Les conditions de validation de la plage horaire sont à implémenter au niveau du backend.
HAKIZIMANA Aymar Davy: US06 - Choisir la marque et modèle de la voiture
In progress.
Un système qui permet à l'utilisateur de choisir la marque et modèle a été mise en place dans le frontend, ce système sélection son choix et va lui envoyer la marque et modèle qui ont été sélectionné
- Faire une requête qui récupère les voitures de même marque et modelé
- Lancer une requête qui récupère les voitures disponible correspondent au modèle de la marque demander par l'utilisateur
- L'affichage dans la liste des voitures
- Le message de retour après validation
- Le message de retour si la marque ou modèle demander n'est pas disponible