Fork me on GitHub
#matrix
<
2023-05-29
>
Benjamin C09:05:00

In f/mx, would we need to make a custom widget to handle things that should be managed according to the flutter lifecycle? Or do we already have some mechanism for that? IE. While this widget is mounted, (stop on unmount), refresh relevant data from the server every N seconds.

2
kennytilton14:05:37

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. :)

kennytilton15:05:57

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.

kennytilton15:05:51

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.

kennytilton17:05:48

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.

Benjamin C18:05:41

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 🙂 .

kennytilton20:05:17

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!

Benjamin C20:05:25

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

👍 1
kennytilton13:05:25

Thinking about this, I am wondering if the widget will later be remounted? I will proceed as if the answer is no, then we can adjust if it is yes. more in a sec....

kennytilton20:05:17

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!