arnaudderison/socialnetwork

Projet dans le but de créer un réseau social.

socialnetwork's Issues

test

Voici le meilleure teste

Code review

Salut Arnaud,

J'ai regardé ton code et il y a de bonnes choses, particulièrement pour ton niveau d'études. Les remarques que je vais formuler ne sont destinées que dans le but de t'améliorer et ne constituent pas une critique personnelle ;-)

Backend

• En général, la racine d'un projet ne contient pas de code. Le fichier server.js n'y a donc pas sa place. On va habituellement retrouver le code sous src, ou dans ton code vu que tu as un monorepo, dans un répertoire server par exemple (et le fichier server.js peut être renommer en index.js.
• C'est une bonne idée de regrouper l'aspect configuration au sein d'un seul fichier et abstraire l'utilisation des variables d'environnement. Par contre, tu pourrais utiliser l'opérateur "backtick" pour construire ta chaine de caractères: `mongodb+srv://${process.env.DB_USER_PASS}@cluster0.039jg.mongodb.net/socialNetwork` (c'est un plus lisible selon moi).
• A différents endroits tu mélanges l'utilise de code asynchrone et de promesses. Je pense qu'il serait préférable de garder une seule ligne de conduite. Si tu veux mon avis, le code asynchrone est plus lisible (async + await)
• La taille maximale d'un fichier uploadé pourrait être une valeur configurable
• Quand tu créé un nouveau post, il serait judicieux de vérifier que le postId existe dans la collection des utilisateurs
• Idem pour la mise à jour, la suppression, ou le like/unlike d'un post, tu devrais d'abord t'assurer que le post existe, et si ce n'est pas le cas, retourner une erreur 404
• Sinon, c'est déjà une bonne idée de valider les ID avec ObjectId mais tu pourrais rendre ton code au sein du controller plus propre en le faisant dans un middleware (surtout que tu répètes cette opération de nombreuses fois)

Frontend

• On a souvent tendance a regrouper les éléments semblables ensemble (pages, actions, components, etc.), mais une organisation par "feature" est généralement plus pratique car tu retrouves tout ce qui concerne une feature au même endroit
• Dans App.js, tu utilise un hook useEffet mais tu ne lui passes pas l'array de dépendance, ce qui veut dire que ton hook sera exécuté à chaque redraw de ton app, ce qui peut être couteux et inutile
• Il serait peut-être utile quand ton application va grossir un peu de séparer certains composants en deux parties: des "smart" components et des "dumb" components. Autrement dit, des composants de logique métier et des composants de présentation. Exemple avec SignInForm.js que tu pourrais scinder en un composant SignIn qui contient la logique de validation des valeurs et l'appel au backend, et un SignInForm qui lui gère le formulaire et son état. Tu peux trouver des exemples ici où j'ai placé les dumb components dans le répertoire /components et les smart dans le répertoire /containers.
• Dans le frontend tu pourrais aussi profiter d'async/await pour rendre le code plus lisible et maintenable
• Tu ne devrais (presque) jamais manipuler le DOM toi même ! Dans SignInForm.js tu ajoutes les erreurs d'une façon "non React". En ligne 24 tu devrais plutôt ajouter les erreurs avec un setter reçu via useState et en ligne 50 afficher les erreurs avec la variable reçu avec le même setter (comme tu le fais pour le champ email...)
• Afin de simplifier la création d'un nouveau state dans les reducers, je ne peux que tu conseiller d'utiliser immer
• Si tu veux désactiver l'extension de navigateur React en production, tu peux utiliser ceci: https://www.npmjs.com/package/@fvilers/disable-react-devtools
• Je vois que tu as un fichier de reset CSS, sache que c'est déjà fourni par l'outil "Create React App"

Voila, je n'ai pas approfondi plus que ça mais lu en diagonale. Comme je te l'ai déjà dit, c'est un très bon début, et qui sait une future carrière qui part sur une bonne voie...

Bon courage,
Fabian