loicsalou / ma-cave Goto Github PK

Toute mise à jour= d'une bouteille, y compris la mise en favoris, perturbe l'ordre de tri de la liste:. Là où les bouteilles mises à jour se retrouvent à la fin de la liste.
Veiller à ne pas changer le tri.
Vérifier également pour les slides des casiers, il y a lee phénomène quand on modifie un casier.

actuellement toute mise à jour d'une bouteille déclenche le renvoi depuis la DB de toutes les bouteilles, ce qui génère un traffic réseau optimisable, et ce qui pourra avoir son importance si on utilise un jour firebase pour la production: le tarif dépend de la consommation de données. De plus les utilisateurs ayant éventuellement un forfait data limité seraient amenés à télécharger plus que de nécessaire.

Solution: sur le FirebaseDataConnection.fetchAllBottlesFromDB(), faire un take(1) pour ne charger ça qu'une fois puis mettre en place un observable sur les bouteilles ayant une date-time de mise à jour > à la date où on a consommé l'event de fetchAllBottlesFromDB.

Répercussions sur le BrowsePage, probablement le dashboard, à voir pour CellarPage.

En offline on doit pouvoir faire seulement de la consultation. Pour cela on ne devrait pas avoir à gérer à la main l'interdiction d'utiliser la connection firebase dispo sur l'écran de login

Quand on zoom sur un casier il peut déborder de l'écran. Quand alors on passe au casier suivant on voir sur le slide non seulement le casier du slide comme c'est logique mais aussi un bout du casier qui déborde du slide précédent.

L'utilisation du slider est discutable, il empêche l'utilisation correcte du zoom sur un casier, car si on zoome sur un casier et que celui-ci déborde de l'écran il faut pouvoir slider afin d'accéder à toutes les cases, ce sans changer de slide.
Voir si on peut avoir un meilleur contrôle du slider ou supprimer le slider et changer de navigation entre les casiers

Quand la bouteille à des photos attachées l'image qui apparaît dans la liste met du temps à se charger. Faire en sorte d'utiliser les mêmes icônes partout dans la liste, pas l'image de profil.

Le message "le nombre max de rangée est atteint" ou un message du genre, alors que ce n'est pas le cas.

l'actuel popup se ferme beaucoup trop tôt.

dans certains cas apparemment après un filtrage au lieu de réinitialiser la liste des bouteilles quand on la reçoit on ajoute à la liste actuelle ce que l'on reçoit.
Pour reproduire on peut sélectionner quelques bouteilles et les mettre en favori, ça provoque le cas (mais pas seulement)

Gérer les autorisations android explicitement car sinon parfois on a des problèmes difficiles à résoudre. Ex. l'importation de la data ne fonctionnait plus à cause d'une autorisation android nécessaire mais l'app ne la demandait pas, il a fallu que j'aille dans les propriétés de l'app sur mon téléphone pour lui donner explicitement la permission d'accéder au storage.

tous les users sont enregistrés grâce à une adresse mail.
Si quelqu'un s'enregistre à la fois via FB et via son mail, et que ce mail est le même que celui de FB on a une erreur de login car le compte est déjà utilisé.

bizarrement on se retrouve avec une boucle sur l'observable filteredBottles après avoir joué un peu avec l'historique. Par réussi à déterminer l'élément déclencheur mais si on joue avec et qu'on navigue sur une ou plusieurs bouteilles, parfois en revenant sur la liste des bouteilles ça part en boucle.
Il semble que le switchHistory déclenche le filtrage qui rafraichit la liste mais que du point de vue angular, les données pour le binding ont été changées depuis le check (un problème d'asynchronisme à priori) et du coup on boucle sur l'événement semble-t-il déclenché depuis la vue par le ionChange sur la checkbox history.

le back hardware des téléphones devrait être autorisé dans la mesure où il ne provoque pas la sortie de l'application (confirmer comme actuellement dans ce cas).

Remettre ça en place.

mettre en place un error handler qui logge tout dans firebase, cela permettra de debugger plus facilement sans bloquer l'utilisateur

depuis le dashboard ou un des onglets de la page principale si on fait back on retourne sur l'écran de login alors qu'on est déjà loggé ==> ne pas permettre ça car on double les observers

toutes les queries textuelles sont enregistrées pour pouvoir être rejouées via le dashboard mais il faudrait n'enregistrer que celles qui ramènent au moins une bouteille, cela éliminerait la plupart des fautes de frappe.

en naviguant il peut arriver qu'on fasse un "back" soft (sur android par ex) qui, sur le NavRoot, provoque la sortie de l'application.
Empêcher ça.

le menu de filtrage dans le browse ne s'affiche pas tout le temps, ceci est dû au fait que l'on peut naviguer sur la page de browse depuis plusieurs navControllers (les tabs, et le navCtrl du dashboard qui passe un filtre à la page par ex. après un clic sur un graphe). le menu est ouvert dans une page et ne s'ouvre donc pas dans l'autre.

Ceci apparaît comme un dysfonctionnement, je vois plusieurs solutions possibles

• la plus simple: supprimer le tab de browse. Ai l'on ajout un raccourci, dans le dashboard, sur la totalité des bouteilles on aura assez de raccourcis pour pouvoir s'en passer.
• idéalement: tout événement de navigation depuis le dashboard devrait passer par les tabs. On pourrait sélectionner le tab du browsePage en lui passant un paramètre via un output du dashboard ?
• avec un navigation handler global de type observable qui doit géré depuis la TabsPage pour avoir une navigation centralisée (+- idem solution précédente)
• voir si l'on ne peut pas avoir 2 fois la même page de menu (FilterPage) ouverte en 2 endroits différents
• s'arranger pour que la FilterPage soit fermée proprement quand on quitte la page dans laquelle elle est utilisée

Ajouter des tests unitaires et end to end.

Ajout d'animations et transitions sympa sur les actions dynamiques, comme le déplacement de bouteilles, l'agrandissement / la réduction des casiers etc.

Apparemment certains casiers ont des dimensions x y numériques, d'autres alphanumériques.
du coup le total (opération reduce dans le canIncreaseHeight) fait "02"+5="025" au lieu de 7 et on se fait bloquer...

la gestion des observables est complexe, je les ai créés alors que je connaissais mal tout ça.
Reprendre l'application et introduire un vrai state management en s'appuyant sur NGRX.

quand on efface la photo de profile d'une bouteille, et qu'on fait une màj de cette même bouteille, le save se plante, on essaie de sauvegarder la valeur undefined (non supporté par JSON).

2 classes Bottles et Configuration contiennent des données statiques telles que les couleurs du vin, les régions, les appellations par région etc.
Reprendre ça proprement dans une classe de configuration injectée là où c'est utile, mais centraliser ces données

il faut cliquer sur le texte de la navbar, celui qui indique la recherche en cours, ex. "deiss blanc 2002" et "12 bouteilles sur 525", pour faire apparaître la zone de search. Cela n'est pas intuitif pour les utilisateurs qui du coup ont un manque de cette fonctionnalité.

Mettre au moins le logo de la recherche (loupe) pour indiquer qu'on peut le faire.

Voir ici:
https://medium.com/@tiangolo/angular-in-docker-with-nginx-supporting-environments-built-with-multi-stage-docker-builds-bb9f1724e984

la couche de persistence gère des Subjects de partout, ce n'est probablement pas nécessaire. Utiliser des classiques observables basés sur des connexions HTTP et supprimer la complexité inutile.

grâce à un bug dans l'importation je me rends compte que les observables instanciés au niveau des déclarations des attributs posent un problème: quand on se déconnecte de l'application, les observers se sont bien "unsubscribed" mais les observables restent instanciés avec tous leurs observers , du coup la souscription reste mais ne fonctionne plus ==> il faut donc instancier les observables dans une méthode d'instance plutôt qu'au niveau des attributs de façon à ce qu'après un logout / login on puisse réétablir la connection entre l'observer et l'observable.

Vérifier tous les observables.

utiliser une couche de cache basée sur un interceptor et une librairie de caching.
Le mode déconnecté sera revu après.

A l'époque où j'ai commencé cette application je n'avais pas le dixième du recul nécessaire sur Angular. En conséquence le code est parfois mal fichu. Notamment les modules. Il faut faire:

• 1 app module
• 1 core module pour les providers singleton
• 1 shared module pour les composants partagés entre les feature modules
• 1 feature module par domaine de l'application. Les principaux domaines que je vois sont:
  -- l'affichage et la recherche des bouteilles
  -- la gestion des casiers
  -- les fonctionnalités de mise à jour
  -- l'administration (profile, admin features comme l'upload)