-
Notifications
You must be signed in to change notification settings - Fork 3
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(social): commente un bouquet #180
Conversation
✅ Deploy Preview for ecospheres ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Pourquoi ne pas commencer par la visualisation des discussions, pour pouvoir ensuite implémenter la création de commentaires de bout en bout ? Nitpick : Ce serait bien de séparer les cleanups dans des PRs séparées pour faciliter la review. Les PR peuvent être stacked (EC-128-Discussion-bouquet -> cleanup -> main), comme ça EC-128-Discussion-bouquet est automatiquement rebased sur main lorsque cleanup est mergée. |
Cette functionnalité à effectivement plusieurs entrées :
J'ai proposé lors de l'atelier de démarrage qu'on commence comme tu dis :
Il a été acté de commencer par la création, et ce ticket suit tout simplement cette logique.
Effectivement ! Bonne idée. (Note tout de même que le format est automatique maintenant à chaque commit) |
J'ai déjà dit qu'il me semble plus cohérent de commencer par la visualisation, donc je n'ai pas d'autre élément à apporter. En revanche, je vous laisse voir avec @edelagnier ce qui vous semble plus pratique côté implémentation.
J'avoue. Une autre idée, ce serait de faire #157 et #65, si tu te sens motivé 🙏 😃 (cc @abulte aussi) |
e6c65f8
to
773eebe
Compare
773eebe
to
4b68205
Compare
|
bon pour moi cote code d'appel API, préférez vous qu'on attende d'avoir l'interface graphique pour merger ? |
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.
Ok pour moi aussi (modulo ma question sur le await), mais j'ai tendance à préférer une PR bout-en-bout sur des petites modifs ; ça clarifie l'usage et permet de tester la fonctionnalité directement.
Vu que la PR est prête, faites comme vous le sentez.
async delete(entityId) { | ||
return this.httpClient.delete(`${this.url()}/${entityId}/`).then( | ||
async delete(entityId: string): Promise<Response> { | ||
return await this.httpClient.delete(`${this.url()}/${entityId}/`).then( |
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.
Le await
est nécessaire ?
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.
@edelagnier ? (Il me semble que c'est le npm run format
qui rajoute ça automatiquement).
#handleError({ response, message }) { | ||
if (response) return { status: response.status } | ||
return { message } | ||
#handleError({ response, message }): Response { |
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.
@edelagnier vu que c'est du TypeScript maintenant, ne pourrait-on utiliser private
plutôt ?
#handleError({ response, message }): Response { | |
private handleError({ response, message }): Response { |
J'ai marqué cette PR comme draft, car elle depend fortement de #205. |
Closes #128
Depends on #198
Depends on #205
Changement technique
Contexte ou situation
Je m'attends à pouvoir créer un commentaire sur un bouquet.
Problème rencontré par les utilisateurs
Ce n'est pas le cas, mais c'est possible via l'API data.gouv.fr.
Proposition de solution au problème
Qu'est-ce qui change ?
Modifications techniques