STEINNI
81 lines
5.1 KiB
Plaintext
81 lines
5.1 KiB
Plaintext
***********************************************
|
|
* Raiders of the lost-arcmodel (archaïc model)*
|
|
***********************************************
|
|
|
|
===> Le comportement zarb:
|
|
On édite une propal, on refocus le dashboard, on clique sur view de la même propal (probablement idem si edit) :
|
|
La propal se re-focus, mais les dernières données encodées n'y sont pas.
|
|
Biensur, réessayé en veillant bien à attendre le temps de l'auto-save,
|
|
vérifié en voyant passer le PUT en console-network mais le blème est bien côté FE.
|
|
|
|
|
|
|
|
===> L'enquête:
|
|
- Suivit le reloading des données en les dumpant partout, depuis le modèle (reload OK, données fraiches, donc effectivement c'est pas le BE)
|
|
jusque dans la vue ou -surprise- elles sont périmées.
|
|
- Pourtant séquence temporelle correcte, on a bien le model.getPropa avant le view.fill
|
|
- Finalement soupçon sur l'instantiation des modèles => mise (temoraire) d'un UUID random comme propriété du modèle dans son constructeur.
|
|
Du coup on peux tracer les changements d'instance.
|
|
|
|
|
|
===> Le diagnostique:
|
|
L'utilisateur sur le dashboard, fait un "Edit" sur la propal (première ouverture de cette propal):
|
|
- Route vers "SubmissionController::proposal"
|
|
- Ctrl instancie le model submissionModel (instance SM1)
|
|
- Ctrl load les datas dans SM1.data
|
|
THEN il fait un this.loadwindow (SumissionShortForm2023View), passe tous les modeles (dont SM1)
|
|
son ancêtre "EICcontroller" fait un "createwindow", et un "loadview" : param "data.models" =tous les modeles (dont SM1)
|
|
- "DOMContentLoaded(options)" est lancé dans la view "SubmissionShortForm2023View", SM1 arrive par "options.models", devient "this.submission"
|
|
- La view-propal fait des "fill()" pour tous les tabs, prend ses datas dans "this.submission" donc dans SM1.data ===> all good
|
|
|
|
- Ensuite, le user refocus la fenetre dashboard et fait un "view" sur la même propal. (probablement un "edit" aurais le même comportement)
|
|
- Route vers "SubmissionController::proposal"
|
|
- Ctrl instancie le model submissionModel (instance SM2) ====> aie !
|
|
- Ctrl load les datas fraiches dans SM2.data
|
|
THEN il fait un loadwindow (SumissionShortForm2023View), passe tous les modeles (dont SM2)
|
|
son ancetre "EICcontroller" conmait cette fenetre, et donc fait un "this.focus" (pas un create) param "data" = tous les modeles (dont SM2)
|
|
- "DOMContentFocused(data)" est lancé dans la view "SubmissionShortForm2023View", qui recoit SM2 via options.models
|
|
- MAIS "DOMContentFocused" se fout pas mal de options.models ====> ouille !
|
|
This.submission reste donc l'instance SM1 pas fraiche ====> et bardaf, c'est l'embardée !
|
|
|
|
|
|
- Biensur, Si on continue les allez-retour, il y a chaque fois une nouvelle instance de modèle,
|
|
mais les tabs continuent d'utiliser la toute première instance ===> aie-ouille-bardaf !
|
|
|
|
|
|
===> Le fix:
|
|
|
|
1. Patché d'abord en réassignant les modèles dans DOMContentFocused de "SubmissionShortForm2023View". (fastoche)
|
|
|
|
!!! Oui mais, dans le cas des Tabs ca ne suffit pas, car les tabs ne sont pas réinstanciés nonplus.
|
|
De plus, leur "DOMContentFocused" n'est jamais appelé.
|
|
|
|
2. Ajouté un appel à "DOMContentFocused" pour tous les chunks.view dans "SubmissionShortForm2023View::DOMContentFocused" pour propager le focus aux tabs
|
|
|
|
3. Ensuite ajouté un "DOMContentFocused" dans la maman des tabs "SubmissionShortFormTabView" qui assigne this.model avec options.models.sumbission (options.models étant maintenant dispo)
|
|
|
|
Du coup les vues & tabs ont la dernière instance du modèle, créée en réentrant dans le CTRL et donc les données fraiches.
|
|
...Reste a espérer qu'il ne traine plus de refs sur la vielle instance de modèle et qu'elle soit donc proprement garbage-collectée.
|
|
|
|
|
|
Attention, du coup sémentiquement : "DOMContentFocused" d'un tab veux dire "la fenêtre à laquelle le tab appartient est refocussée",
|
|
a ne pas confondre évidemment avec le focus du tab lui-même ( = event 'selected' du composant).
|
|
|
|
|
|
Makes me wonder : dommage qu'on réinstancie le modèle (en général, même fenêtre (avec mêm url dont params) = mêmes données,
|
|
le rafraichissement éventuel des données pourrais aussi bien se faire sans changer d'instance de modèle.
|
|
Mais lorsque EICcontroller teste pour voir si c'est une fenetre connue, il est déjà trop tard :
|
|
le ctrl-fiston a déjà instancié et choppé les datas, d'ailleurs c'est même obligatoirement synchrone avant de lancer la fenetre : via le THEN)
|
|
D'un autre côté, créer une association modèle-window (pour savoir si on l'a déjà plus tôt) n'est clairement pas un bon pattern...
|
|
... A méditer avec un malibu-ananas.
|
|
|
|
Si on reste sur le patch ci-dessus, faut bien garder ca en tête paske ce pattern => bug potientiel va se retrouver ailleurs !
|
|
|
|
|
|
|
|
===> Side-effect & Fix on the fix :
|
|
Dans certains cas les focus sont appelés sans options (lorsqu'on clicke sur les badges fenêtre).
|
|
=> rajouté un test pour ne pas tenter de recopier les modèles si pas d'options.
|
|
Pas grave parceque ca correspond au cas ou on refocus la fenêtre sans rerouter, donc avec modèles non-réinstanciés.
|
|
Mais j'adore pas tout ca... faudrat qu'on en cause, voir si on peut clarifier/simplifier.
|