-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(conversation): #WB-3633, services, queries, routing and basic pages of React app #562
Conversation
conversation/frontend/src/features/ActionBar/ActionBarContainer.tsx
Outdated
Show resolved
Hide resolved
* Utility function to HTTP PUT an optional payload to an endoint. | ||
* Then discard the response to void. | ||
*/ | ||
function putThenVoid(endpoint: string, payload?: any) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pourquoi utiliser ça ? c'est parce que le back nous retourne des résultats étrange genre {number: 1}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Effectivement, je me pose la même question ... pourquoi ne pas faire du DTO propre ? et pourquoi chainer avec des NOOP ? Si parce que le code back pue la merde, faut pas rendre le front illisible :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Si on a les données sont dans le payload on peut retourner un objet propre pour que le composant puisse l'utiliser facilement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comme indiqué en commentaire dans le code, cela défausse la réponse du back vers le néaaannnnt
Mais en quoi est-ce illisible ? C'est encapsulé dans un unique fichier, sans incidence sur le reste du code de l'appli, et factorisé pour pouvoir être modifié facilement plus tard. Je ne vois pas de problème personnellement.
Le payload est spécifique à chaque endpoint du backend.
=> On ne pourra pas retourner un DTO propre au niveau des services, puisque ces appels d'API ne disposent pas de toutes les données ni en entrée, si en sortie.
Par contre, on doit pouvoir un pseudo-state propre au niveau des queries qui utilisent ces services.
Mais du coup, il vaudra peut-être mieux maintenir un vrai state zunstand ??
Je militais au départ pour refaire une API backend à 100%, mais... comme tu dis.
…ges of React app (#562) * feat(conversation): #WB-3633, initial commit * wip * wip * wip * fix: rename routes * wip * fix: lint error * fix: redirection for hash-based folders URLs * feat: create folder and message API service factories * wip: folder and message queries * wip: message queries + simplifications * fix: feedback from PR * fix: feedback from PR * fix: feedback from PR * feat: folderService tests * feat: messageService tests
…ges of React app (#562) * feat(conversation): #WB-3633, initial commit * wip * wip * wip * fix: rename routes * wip * fix: lint error * fix: redirection for hash-based folders URLs * feat: create folder and message API service factories * wip: folder and message queries * wip: message queries + simplifications * fix: feedback from PR * fix: feedback from PR * fix: feedback from PR * feat: folderService tests * feat: messageService tests
Description
Implement some basic React pre-requisites :
Fixes
WB-3633
Type of change
Please check options that are relevant.
Which packages changed?
Please check the name of the package you changed
Tests
Tests are still to be written.
Reminder
Security flaws
Performance impacts (think bulk !)
Unit tests were replayed
Unit tests were added and/or changed
I have updated the reminder for the version including my modifications
All done ! 😃