Skip to content
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

Closed

Conversation

bonjourmauko
Copy link
Contributor

@bonjourmauko bonjourmauko commented Nov 23, 2023

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

  • Implémente la création d'une discussion autour d'un bouquet.

Qu'est-ce qui change ?

Modifications techniques

  • 🤟 Commenter un bouquet (via l'API).

@bonjourmauko bonjourmauko added the enhancement Améliorations et nouvelles fonctionnalités label Nov 23, 2023
@bonjourmauko bonjourmauko added this to the V1 : Découvrabilité par cas d’usage milestone Nov 23, 2023
Copy link

netlify bot commented Nov 23, 2023

Deploy Preview for ecospheres ready!

Name Link
🔨 Latest commit
🔍 Latest deploy log https://app.netlify.com/sites/ecospheres/deploys/655f83477dfa151ac49da981
😎 Deploy Preview https://deploy-preview-180--ecospheres.netlify.app/
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@bonjourmauko bonjourmauko requested a review from streino November 23, 2023 14:04
@streino
Copy link
Contributor

streino commented Nov 23, 2023

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.

@bonjourmauko
Copy link
Contributor Author

Pourquoi ne pas commencer par la visualisation des discussions, pour pouvoir ensuite implémenter la création de commentaires de bout en bout ?

Cette functionnalité à effectivement plusieurs entrées :

  • si je suis en train de créer un bouquet : commenter -> visualiser
  • si je suis en train de naviguer les bouquets : visualiser -> commenter

J'ai proposé lors de l'atelier de démarrage qu'on commence comme tu dis :

  • d'abord la navigation des bouquets (avec des bouquets fake)
  • et ensuite la création des bouquets

Il a été acté de commencer par la création, et ce ticket suit tout simplement cette logique.

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.

Effectivement ! Bonne idée.

(Note tout de même que le format est automatique maintenant à chaque commit)

@streino
Copy link
Contributor

streino commented Nov 24, 2023

Cette functionnalité à effectivement plusieurs entrées :
* si je suis en train de créer un bouquet : commenter -> visualiser
* si je suis en train de naviguer les bouquets : visualiser -> commenter

J'ai du mal à conceptualiser le 1er cas.
Pour moi dans tous les cas on a visualiser -> commenter.
Même lorsque la discussion n'existe pas encore il faut la visualiser, par exemple data.gouv :

Il a été acté de commencer par la création, et ce ticket suit tout simplement cette logique.

Pour la création de bouquets, oui. Mais je ne vois pas en quoi la décision sur les bouquets s'applique automatiquement sur les discussions. Selon la même logique, on a une section qui visualise les jeux de données dans la création de bouquets, mais on a pas décidé de commencer par la création de jeux de données.

(Note tout de même que le format est automatique maintenant à chaque commit)

Comment se fait-il qu'on ait encore des reformat automatiques si le format est fait à chaque commit ?

Je regarderai si on peut appliquer le format qu'aux fichiers modifiés qui sont commit, pour éviter de polluer automatiquement les PR. Sinon c'est vrai que ça demande un peu de gitfu pour récupérer le truc. En attendant, on peut aussi tjs passer manuellement le format avant.

@bonjourmauko
Copy link
Contributor Author

Cette functionnalité à effectivement plusieurs entrées :

  • si je suis en train de créer un bouquet : commenter -> visualiser
  • si je suis en train de naviguer les bouquets : visualiser -> commenter

J'ai du mal à conceptualiser le 1er cas. Pour moi dans tous les cas on a visualiser -> commenter. Même lorsque la discussion n'existe pas encore il faut la visualiser, par exemple data.gouv :

Il a été acté de commencer par la création, et ce ticket suit tout simplement cette logique.

Pour la création de bouquets, oui. Mais je ne vois pas en quoi la décision sur les bouquets s'applique automatiquement sur les discussions. Selon la même logique, on a une section qui visualise les jeux de données dans la création de bouquets, mais on a pas décidé de commencer par la création de jeux de données.

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.

(Note tout de même que le format est automatique maintenant à chaque commit)

Comment se fait-il qu'on ait encore des reformat automatiques si le format est fait à chaque commit ?

Je regarderai si on peut appliquer le format qu'aux fichiers modifiés qui sont commit, pour éviter de polluer automatiquement les PR. Sinon c'est vrai que ça demande un peu de gitfu pour récupérer le truc. En attendant, on peut aussi tjs passer manuellement le format avant.

J'avoue. Une autre idée, ce serait de faire #157 et #65, si tu te sens motivé 🙏 😃 (cc @abulte aussi)

@streino streino assigned edelagnier and unassigned YeLnatSs Nov 24, 2023
@bonjourmauko bonjourmauko changed the title feat(api): commente un bouquet api(social): commente un bouquet Nov 28, 2023
@bonjourmauko bonjourmauko added api and removed enhancement Améliorations et nouvelles fonctionnalités labels Nov 28, 2023
@bonjourmauko bonjourmauko changed the base branch from main to build/applique-format November 28, 2023 17:14
@bonjourmauko bonjourmauko force-pushed the EC-128-Discussion-bouquet branch from e6c65f8 to 773eebe Compare November 28, 2023 17:17
@bonjourmauko bonjourmauko force-pushed the EC-128-Discussion-bouquet branch from 773eebe to 4b68205 Compare November 28, 2023 17:19
@bonjourmauko
Copy link
Contributor Author

⚠️ rebased and force-pushed cc @edelagnier

@bonjourmauko
Copy link
Contributor Author

@streino Pour faciliter la discussion, j'ai réduit le périmètre de cette PR à #199 (API) et te propose qu'on poursuive la discussion concernant le côté front ici. Si cela te convient 😃

Base automatically changed from build/applique-format to main November 29, 2023 00:12
@edelagnier
Copy link
Contributor

bon pour moi cote code d'appel API, préférez vous qu'on attende d'avoir l'interface graphique pour merger ?

Copy link
Contributor

@streino streino left a 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(
Copy link
Contributor

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 ?

Copy link
Contributor Author

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 {
Copy link
Contributor Author

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 ?

Suggested change
#handleError({ response, message }): Response {
private handleError({ response, message }): Response {

@bonjourmauko bonjourmauko changed the base branch from main to feat/list_topic_comment December 4, 2023 14:42
@bonjourmauko bonjourmauko marked this pull request as draft December 6, 2023 12:39
@bonjourmauko
Copy link
Contributor Author

J'ai marqué cette PR comme draft, car elle depend fortement de #205.

@bonjourmauko bonjourmauko changed the title api(social): commente un bouquet feat(social): commente un bouquet Dec 6, 2023
@bonjourmauko bonjourmauko added enhancement Améliorations et nouvelles fonctionnalités and removed api labels Dec 6, 2023
@abulte abulte closed this Jan 11, 2024
@abulte abulte deleted the EC-128-Discussion-bouquet branch October 28, 2024 16:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Améliorations et nouvelles fonctionnalités
Projects
None yet
Development

Successfully merging this pull request may close these issues.

api(social): commenter un bouquet
5 participants