Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Only lead climbs #60
Only lead climbs #60
Changes from 28 commits
f24cb45
06370da
8a84414
aae75f3
639d7b9
a4d8b2a
8f602ab
bc6a550
60bbf84
23ed5ee
1bf8531
57ae19e
3ace689
5635633
eb27516
659c230
7f53ecd
91e9ddf
9c62971
3edb896
7ca72a4
d1f2ddc
850b170
6dda412
c7bb4d0
79aa86a
fb751ff
c820bcc
35a6319
aa553c7
0a349a0
30214e2
f31f404
c385176
25527f6
3c6814a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
les datas plutôt en camelCase
donc ascentStatusList, ropingStatusList, etc.
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.
J'ai mis en snake case parce que tu l'as demandé pour le backend (oblyk/oblyk-api#9 (comment)). Et effectivement il y a forcément un des deux bouts qui n'est pas vraiment dans la norme. Pour etre plus cnofoirme la seule solution que je vois c'est de convertir le Camel en snake avant envoi de la requete comme ci-dessous. Est ce que ca te vas ?
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.
Finalement c'est beaucoup trop lourd. Dans l'autre sens il faut aussi convertir tous les snakes en camelCase à la réception des données. Tu en penses quoi ?
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.
info: pour repérer ou j'avais des snakes case à remplacer j'ai voulu ajouter ' camelcase: ['error', { properties: 'always' }] ' au linter. Il a sorti 1884 errors. Donc je l'ai enlevé ... Mais ce n'est aps le seul endroit ou on a des snake cases.
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.
Alors oui ce n'est pas ultra régulier que tous soit en camelCase ^^
Grosso modo, sur ruby on rails la convention c'est le snake_case pour les variables
Sur nuxt / js c'est le cameCase, du moins c'est la convention que j'ai choisie
Donc ça fait forcément un mixte de convention.
Par exemple les données issu de l'API sont en snake_case, exemple ascent.roping_status
donc dans le formulaire d'ajout d'une croix, tu va avoir ce genre de code
là par exemple tu as un mixe de variable issu de l'API dans this.data, et des variable qui servent le fonctionnement du front le this.loadingAscent
Donc maintenant ce pose la question de passage d'un paramètre du fonte vers le back, comme ici
Dans la plus part des cas je travail sur le front avec les convention du front, et sur le back avec les conventions du back, donc ça va être au niveau des serviceApi que la conversion va s’effectuer.
exemple:
personnellement ça ne me dérange pas de répéter les filtres passé à l'API, ça facilite la lecture : )
et on peut appeler cette fonction comme ça :
donc par exemple pour statList on travail en camelCase dans le reste du front, il est juste naturellement transformé en en snake_case dans LogBookOutdoorApi au passage par les paramètres
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.
est ce qu'on est d'accord que par contre les data qui remontent de l'api (notamment l'objet stats) restent en snake case, donc par ex on aura
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.
Je ne suis pas sûr de comprend pourquoi ?
ça ne devrait pas être le onSubmit qui $emit ?
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.
On ouvre la form de filtre en cliquant sur le bouton "filtrer".
Tant qu'il est ouvert on peut changer les paramètres du filtre et on observe à chaque changement l'effet sur les stats (le watch) mais sans sauver dans le localStorage.
Quand on clique sur "Save" ca enregistre le noveau régalge de filtres dans le localStorage (le emit)
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.
En local ça doit bien marcher, mais en prod avec des temps de réponse plus long je ne suis pas sûr que l'expérience soit aussi gratifiante.
Surtout si on ne gère pas l'annulation de la requête précédente.
Si tu laisse l'utilisateur envoyer un second filtre avant d'avoir reçu le premier, tu n'as pas la garantie de l'ordre dans lequel tu va avoir les réponses, tu va peut-être recevoir la réponse du deuxième filter, puis du premier, et tu te retrouve avec les croix du premier filtre avec l'affichage du second filtre.
Il fois soit annuler la requête précédente, soit bloquer le formulaire temps que tu n'as pas reçu la réponse du premier, soit filtrer uniquement quand tu clic sur (filtrer)
Je pense que le plus compréhensible, performant et simple c'est la troisième solution.
Un seul bouton (filter) qui envoie la requête et enregistre le filtrer
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 la solution 3