Clojurians Log v2

Case 1: Widget will not be remounted. Ideally, the MX logic (cells and watches) drive everything, so Flutter lifecycle just does its thing in the background as the f/mx decides when to eliminate a widget. One cell decides if widget P (for "poller") is needed. That is likely outside P, somewhere in the container deciding whether to include P. P has a formulaic cell T (for "timer") that "computes" a Timer, cinfigured to fire every N seconds. The Timer handler handles the loading. Cell T should get an :on-quiesce function that cancels the timer. This will be called when the poller P is no longer wanted. This is new code, btw, so lemme know if I should try knocking off an example. If you know what timer you have in mind I'll use that. If any of this ^^^ makes sense, I should add. :)

Hmm, I said "ideally": a non-ideal situation would be one in which we do not control the unmounting. In that case we do need to look to Flutter lifecycle, perhaps in an unmount method. We can also check if the widget is mounted before processing a data packet requested before the unmount came through.

Meanwhile over here I have cobbled together an example with a Timer (no fetch yet) to see if the :on-qiesce mechanism is picking that up when I toss a widget, and -- HEADS UP! -- not yet. Let me at least get this working while we clarify your use case.

OK, the problem was that the cell formula that produces the timer has no dependencies -- it is more of a constructor thing -- and so it gets optimized away. But we still need the :on-quiesce handler! Starting to think optimizing away needs to not eliminate the cell, but rather achieve the same performance win with a minimal "away". Anyway, I can now swap a timer-powered widget in and out and it does the right thing with the timer. Now let's mix in an async fetch.

Ah that makes sense. In my case, come to think about it, I can simply have the fetching formula check if it's on the desired route, and not worry at all about flutter life-cycle 🙂 .

OK, goofy little example of w/mx scavenging a Timer when the owning widget goes south: web/mx SHA: 3f6005c7099fb71aefeb8be168010c95ec5ffb02 NS: tiltontec.example.x035-timer-poll This was useful anyway in surfacing the clash between optimization and scavenging. Thx!

Glad it was useful 🙂 , I was thinking I'd sent you on a needless wild goose chase.