New repeatable not loading data when underlying data changes?

Trying to configure a new Repeatable component to dynamically change the data that is shown, rather like a page view, but based on a List component. Choose from the list component in the sidepanel, what should appear in the listview. (I use a variable for the data which gets updated when the components change (or, in the case of textArea, on blur).

But when I change an item - e.g. type in the textArea component...

The change that I made, is still there even if I select a different item in the List component. All the other components "reload" their data except for the one I changed.

Am I going about this in a bad way? This is how I interpreted the idea of storing data in variables and "keeping track of changes using events". I have a version that is one big list (which works but is not performant). In this case, when typing in a text area, it is possible that mid-typing, the textArea reloads and you lose what has been typed!

Any help much appreciated.

wow, this looks like quite a complex app you've developed with lots of custom logic in there, kudos.

Without getting into the details too much I think there's a few things going on with states and default values that are possibly tripping over one another, based on the behaviours you've described.

I'm interested in the listView you've put in the centre of the app - it appears, in the code, that it would only ever show 1 record? If the intent is to pick from the left listbox and show a single record for editing in the main panel then perhaps a more traditional Form component would be easier for you to manage and keep track of changes, set the values etc?

If the intent is to select multiple records and edit them all simultaneously then that could also be a job for multiple forms inside a listview.

Then when the listbox value changes you can set the value of the form to the selected item in one event handler.
When the form fields are edited you can detect that as another change and use the forms own functions to collect all the edited data for writing back to your data source in an update query.

Thanks @dcartlidge,

I do tend to creep the complexity of the app, because Retool is so cool and can do loads of things.

I realised after posting that my examples were all of single records. There are a mixture of single and multiple records, depending on which item is selected in the listbox and how many of those items there are.

FAD - New edit FAD 3 | Editor - 31 January 2024 - Watch Video

FAD - New edit FAD 3 | Editor - 31 January 2024 - Watch Video

The suggestion you describe seems to be what I thought I had, but I am unsure. I fear that I may have made the logic too complicated.

I use the Blur event to save the value of the TextArea to the variable.

I have another version of this app where all the items are in one big long listView component. This is non-performant too. I think because there are so many components in the container. I am wondering if I try to split this into multiple views (e.g. one for text, one for costs) whether that would improve performance. Interestingly in this version, the textArea components keep getting reset back to default values multiple times as you type, which seems to relate to this article:

but as I'm already using a temp state/variable I can't see how this solution would help me?

Do you have any other ideas?

Definitely looks more complex than a usual app - I think what the issue might be with your "resetting" fields is your blur event handler

It looks like you're setting the value of "Textual_content" in the ObjectsOnAccount variable to whatever the text box contents are for index 0 (if it's the first record)

Looking at earlier screenshots the ObjectsOnAccount variable seems to be an array of objects with ObjectIDs etc - I can see the listbox selection drives the listview, filtered by selected objectID

So I think what I'm guessing at is that your ObjectsOnAccount variable isn't being written to as you expect with that setIn command and, instead, is writing the first record in the array, not the first record in the array that matches the selected ObjectIDs property?

Maybe take a look in the state inspector at your ObjectsOnAccount as you change a text field and see if it's updating the record and textual_content you expect and not replacing the first entity.
That could explain what you're seeing - so when the first text area shows it's default value it's always using the value in index 0, so once you've made a change the textarea will be using that value for every future text box in index position 0.

Hopefully that makes sense?

@jclutterbuck Any updates on this from Retool? I just ran into the same issue when moving from the legacy listView to the new one.

My components here are on change handlers and update a state object, which the listView in turn pulls from. Each component has its default value set to item.attribute_name which should allow the updated values to be pulled into the component when I select a new page. Instead the component maintains its current value.

If not for the limitation of the new component I'd try patching it by just running resetValue() after page changes but now the child components aren't accessible from outside of the LV. :man_shrugging:

User Dashboard | Editor | Retool - 19 February 2024 - Watch Video




@victoria @Tess is there a way to get some visibility to this? I know it’s not tagged as a bug but it does seem to not be working as intended and it’s breaking a reasonably common code pattern.