Le code actuel est un exemple et n'est pas forcément optimal, n'hésitez pas à refaire à votre sauce
Assurez vous d'avoir l'api à jour ! Un petit git pull
avant de commencer ne fait jamais de mal :)
git pull
npm install
npm start
react
documentationreact-router-dom
pour le routingmoment
pour la manipulation des dates et des fonctions bien utiles (ex:date.isAfter(date2)
)react-materialze
pour le style (vous pouvez en utiliser une autre si vous préférez)- Fetch documentation de l'API Fetch.
[GET] /?from&to=from
: Renvoie la liste de toutes les dates de fermetures. On peut filter la liste des dates avec les paramètres from
et get
au format DD-MM-YY.
[GET] /:id
: Renvoie un seul item si il existe
Status des reponses:
- 200: La requete a reussi
- 400: La requete a échoué car les paramètres ne sont pas valides
- 404: La requete a échoué car les paramètres sont valides mais rien n'a été trouvé
- 500: Le serveur a rencontré une erreur
Dans le fichier src/constant.js
, vous pouvez modifier la constante CRASH_EVERY_X_CALLS
par un nombre,
de sorte que le serveur renvoie une erreur 500. Attention, il ne reverra pas du JSON lors d'un crash !
Pour cela, le serveur met un cookie sur votre navigateur pur compter le nombre d'appels. Assurez vous d'envoyer les cookies lors de vos appels
pour que cela fonctionne.
Pour une utilisation avec Fetch
fetch(URL, {
credentials: 'include',
})
.then(...)
Voila la structure minimale de l'application. Vous pouvez faire plus de composants si vous voulez, mais pas moins ! (En revanche, le nom des composants est libre.)
<App>
|__ <HomePage>
|_____ <Search>
|_________ <SearchInput> // recherche le parametre from
|_________ <SearchInput> // recherche le parametre to
|_____ <List>
|_________ <ListItem>
|_________ <ListItem>
|_________ <ListItem> // chaque item doit contenir un lien vers la page Single associée
|_________ ...
|__ <Single>
|_____ <BackButton> // lien vers la homepage
|_____ <PrevButton> // lien vers la date précédente
|_____ <NextButton> // lient vers la date suivante
|_____ <Detail> // Informations sur la date de fermeture
On doit pouvoir arriver sur l'appli à n'importe quelle URL, donc la page single doit appeler la route d'api /:id
et la page homepage la route /
. (En gros, ne pas injecter les données depuis la liste vers la page single)
La liste des features à implémenter, dans l'ordre. Penser à faire un commit par feature, de facon a pouvoir tout casser sans que ca soit le drame ! Il y a une idée de design de l'appli dans le fichier mockup.png
, mais la aussi vous êtes totalement libres.
- Loading: Etat de chargement lors d'un appel à l'api
- Error: Afficher une boite d'alerte lorsque l'api renvoie une erreur (Dans un premier temps gérer tous les types d'erreur indifféremment de façon a ce que l'appli ne crash pas.)
- Routing : depuis la liste vers page single
- Routing : Single vers homepage
- Error: Différencier les types d'erreurs pour afficher des erreurs plus utiles à l'utilisateur. (dates fournies invalides, erreur interne au serveur, ...)
- Search : pouvoir envoyer un paramètre
from
et / outo
pour filtrer la liste (pour l'exercice, on refait un appel a l'API, on ne filtre pas la liste en mémoire). C'est la partie la plus difficile et la plus importante !. A vous de voir quel composant doit faire les appels à l'API, qui gère les états de chargement, les erreurs, etc... - Gérer le cas ou l'api ne renvoie pas de données. (Ce n'est pas une erreur, mais rien ne correspond aux dates fournies)
- Routing : Prev / next sur la single
- Error: Afficher une page 404 si une ID est invalide
- Search : gérer le cas ou on envoie des dates invalides, par exemple si
from
est postérieur àto
. Il est possible que vous deviez casser ce que vous avez déjà fait jusque la. Pensez à commit avant de vous lancer, ou changez de branche :) - Refactoring: Extraire les appels HTTP des composants dans un ficher/une classe à part
- ...