# Flex Repeater Refresh Behavior **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [September 9, 2024, 11:44pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-refresh-behavior/95763 "2024-09-09T23:44:09Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![iss](https://avatars.discourse-cdn.com/v4/letter/i/58956e/32.png) [@iss](https://forum.inductiveautomation.com/u/iss)\ **Post date:** [September 9, 2024, 11:44pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-refresh-behavior/95763/1 "2024-09-09T23:44:09Z")
I have a flex repeater where there's an expression binding on the `instances` list. The expression binding is configured as: `runScript("self.getInstances()", 1000)` where the `getInstances()` method constructs and returns a new instances list. Often, the new list has the same contents as the previous instances list. In this case, are the child components of the flex repeater deleted and recreated? Or are new components only created when the contents of the list change? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 10, 2024, 12:16am UTC](https://forum.inductiveautomation.com/t/flex-repeater-refresh-behavior/95763/2 "2024-09-10T00:16:59Z")
A list is a new object, which is a valid change even if the contents are equal. (Same thing happens with datasets and documents.) So, complete reload. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [September 10, 2024, 6:06am UTC](https://forum.inductiveautomation.com/t/flex-repeater-refresh-behavior/95763/3 "2024-09-10T06:06:34Z")
Is it really a complete reload, though ? It seems to me the flex repeater reuses the instances already created. If you put something in instances that isn't computed from parameters but is recognizable, you can see that it's kept between changes. I experienced it a few times already, the last time being only a few weeks ago when I was implementing a toast system. A flex repeater was calling a `get_queue` function that returned the list of notifications for this session, and used that list as instances. If I tried removing items from the queue, the next item would take its place but would keep things that were not computed from parameters (ie, a timer bar would keep its progress even though the tile was supposed to show a new notification, causing a clearly visible mismatch). I had to work around this by hiding expired/closed notifications instead of removing them, and purging the queue when all notifications were hidden. Or maybe there's something else at play that I missed entirely ? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [September 10, 2024, 12:35pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-refresh-behavior/95763/4 "2024-09-10T12:35:31Z")
> [@pascal.fragnoud](#): > > something else at play Any chance your `get_queue` function was returning the same list view object every time? ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [September 10, 2024, 12:39pm UTC](https://forum.inductiveautomation.com/t/flex-repeater-refresh-behavior/95763/5 "2024-09-10T12:39:38Z")
I thought it wasn't but actually it is ! I went through so many versions of this that my memory got stuck on some older version that did rebuild a new list every time.