Application web sous Next.js permettant de comparer la consommation en CO₂e de divers équivalents.
yarn pour installer l'application
yarn dev pour lancer un serveur de développement sur http://localhost:3000
yarn build pour build l'application
yarn start pour lancer un serveur de production
Le site est hébergé sur Scalingo via des serveurs en France. Aucune donnée ne transite en dehors de l’UE.
-
yarn devlance le serveur web local -
yarn testa:locallance les tests de l'API en continu (avec Jest) -
yarn testu:locallance les tests unitaires en continu (avec Jest) -
yarn teste:locallance les tests de bout en bout ("end-to-end") en continu (avec Playwright)
Lors du premier lancement des tests end-to-end, une installation de Playwright peut être demandée.
Les tests end-to-end nécessitent que le serveur web local soit lancé.
Il vous faut un fichier .env dont les valeurs sont documentées dans .env.dist
Vous pouvez calculer la couverture de test sur votre machine locale.
Si vous n'avez jamais lancé de tests e2e avant, vous devrez installez Playwright en local avec yarn install playwright.
Assurez-vous d'avoir les bonnes variables d'environnement dans le fichier .env, puis installez les dépendances avec la commande yarn, puis lancez le serveur local avec yarn dev.
Ouvrez un autre terminal et lancez les commandes suivantes dans l'ordre :
1 - yarn cov:clean : Supprime le répertoire "coverage" pour partir d'un état propre.
2 - yarn cov:pw : Lance les tests Playwright avec la couverture. Le répertoire "coverage" est alors créé, et contient des fichiers de couverture au format JSON.
3 - yarn cov:jest : Lance les tests Jest, couverture incluse. Le répertoire "coverage" s'enrichit du fichier de couverture des tests Jest, au format JSON.
4 - yarn cov:report : Merge tous les rapports JSON précédents, calcule la couverture finale, et créé un rapport facilement lisible. Le répertoire coverage/summary est alors créé, le fichier index.html contenant le rapport final.
5 - yarn cov:show : Affiche dans votre navigateur le rapport de couverture final (sous coverage/summary/index.html)
La commande yarn cov:full permet de réaliser toutes les étapes de 1 à 5 en une seule fois.
L’organisation du développement suit le workflow Gitflow :
- La branche de production est
main. Seuledeveloppeut être mergée directement dans main. - Les hotfix, comme les features (ou tout autre type de fonctionnalité) sont créés sur des branches dédiées issues de
develop. - Une fois que le code est revu par un pair, et la fonctionnalité recettée par le métier depuis la review app dédiée, il est possible de merger la branche dans
develop. - La branche du travail validé et recetté est donc
develop. Elle possède sa propre review app. Elle est visible ici. - Chaque mise en production consiste à merger
developdansmain.
Les commits sont conventionnés. Les types suivants sont acceptés :
builddocsfeatfixperfrefactorstyletestchore
Parfois les données sont extraites par API.
Parfois les données sont codées en dur.
Il y a un cas de figure entre les deux : un fichier batch se connecte à une API et modifie un fichier .json (qui sera considéré comme "en dur" par l'appli une fois lancée). C'est le cas d'Agribalyse.
Pour mettre à jour ce fichier,
- lancer
yarn build:fruitpour les fruits et légumes, - lancer
yarn build:boissonpour les boissons.
Le projet utilise React avec (entre autre) Nextjs et React Query. Le state est simplement géré par Context.
Le repo est architecturé avec les dossiers suivants :
pagesavec l'ensemble des pages du site.testucontient les tests unitaires (au sens strict, c'est-à-dire les tests d'une fonction)testacontient les tests de l'API (toutes les fonction sous le répertoire /api)testccontient les tests de composants fronttestecontient les tests end-to-endsrcavec tout le reste du code.componentsavec l'ensemble des composantsbaseavec les composants simple réutilisés partout (un peu comme les atomes pour l'atomic design)chartsavec les différents graphique utilisés sur le sitelayoutavec les composants de structure globale (header,footer, etc.)miscavec les composants qui ne rentrent pas dans les autres dossiermodalsavec les différentes modals utilisées sur le site (elles sont déclaré sur le site site via leur provider)providers(qui pourrait être renommécontext) avec les contexts et leur provider (dans le même fichier, ce sont les seuls composants qui ont deux exports)screenshotavec tous les composants spécifiques à la prise de screenshots (boutons, signature, etc.)viewsavec les composants spécifiques à une page[categorie]certains dossiers portent le nom d’une catégorie. Ils contiennent tous l’affichage et la logique spécifique à cette catégorie (et ses équivalents). Ce qui inclue composants et context/provider. Seules les modals restent centralisées dans le dossiermodals
dataavec l'ensemble des données locales importées au buildhooksavec ...les hooksutilsavec quelques fonctions et les bases du css
Les composants (en dehors des providers et des modals) sont regroupés par feature. Chaque composant enfant est dans un dossier du nom du composant parent, à la racine du composant parent. Si un enfant à plusieurs parents, il migre dans le dossier misc. Si un groupe de composants dans le dossier misc devient suffisamment important pour mériter son propre dossier, il migre à la racine du dossier components, dans un dossier au nom approprié.
Chaque fichier de composant (sauf les providers) n'a qu'un seul export : le composant. L'intérieur de ce fichier est structuré comme suit :
- Import de librairie externes (React, Styled Components, etc.)
- Import de librairie interne (d'autres composants que l'on a créé)
- Déclaration et export du composant
Les fonctions appelées dans le jsx ne sont pas nommées, afin de simplifier la lecture. On essaie de maintenir les fichiers de composants bien en dessous de 100 lignes
Le contenu peut être intégré par nos utilisateurs directement dans leur propre site web grâce aux iframes.
Le contenu des iframes est disponible dans le code dans le répertoire pages/iframes.
Ce contenu est donc disponible en ligne à l'URL /iframes/... comme par exemple l'habillement ou la livraison.
Mais ces pages ne sont pas faites pour être lues "telles quelles" dans notre site, mais pour être intégrées dans un autre site.
Ces pages deviennent disponibles à nos utilisateurs grâce à un script qui construit une iframe et l'insère dans le DOM de leur site web.
le script est generé via :
- iframe/index.js
Ce script est minifié, renommé et placé dans le répertoire /public à chaque build du projet NextJS, grâce au fichier webpack.config.js. Ainsi,
- iframe/index.js devient accessible publiquement sous l'URL /iframe.js,
Les utilisateurs qui veulent cette iframe dans leur projet n'ont plus qu'à copier/coller le code suivant dans la page web de leur choix (exemple pour la livraison) :
<script
name="impact-co2"
src="https://impactco2.fr/iframe.js"
data-type="livraison"
data-search="?theme=default"></script>Les attributs "data" permettant de paramétrer cette iframe.
Une API du site est actuellement disponible, sa documentation publique est en cours de construction.
Toutefois, pour les développeurs, afin de comprendre son utilisation et les retours attendus, le répertoire testa regroupe les tests automatisés concernant l'API uniquement.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent