So this is fun, over in the f/mx project:
• Background: I do not always worry about rebuilding all the widgets under a container if I just need to add or remove one;
• MX does have an API for that, which btw goes further than just having a :key on each item;
• in the f/mx TodoMVC, I did not worry about regenning all the children, I did so;
• Problem: after adding a new todo, all existing todo view widgets misbehaved a couple of ways;
• The misbehavior made me wonder if I was looking at Flutter items not aligned with the f/mx items;
• Reading up on Flutter lifecycle and unmount, I saw internally it looked at the list view item :key to decide when to keep a widget;
• I was using a Dart ValueKey based on the Todo's local storage key. Which does not change during the life of a Todo. Uh-oh!
• I temporarily switched to UniqueKey and the app now works. Yay.
• But now I have to swicth back to ValueKey and manage f/mx list view item proxies so they stay around and hopefully that will get F and F/mx on the same page.
This should go in the wiki under Common Mistakes or sth
Voila: https://github.com/kennytilton/flutter-mx/wiki/Gotchas
Interesting result on the Flutter "context" front: a little print diagnostic left in place to see if the context changes for a given f/mx widget build function now fires if we add or remove an item. This using a ValueKey on the unvarying storage-id. So, yeah, Flutter keeps the same internal structure, but it "moves" it to a new Element.
Fun note: it does that for all subcomponents of the item as well.
OK, quiescing seems fine now that I am careful about reusing proxy items where Flutter will be reusing native items. This is what I was too lazy to write, costing me two days:
(map (fn [todo]
(let [stg-id (td-stg-id todo)
exg (some (fn [li]
(when (= stg-id (.-value ^m/ValueKey (mget li :key)))
li))
_cache)]
(or exg (todo-list-item todo))))
(sort-by todo/td-created-at
(todo/app-todos (my-app))))
sigh
Now I will turn the above into a reusable kids generator. For lazy people. 🤣