Query getting slower and slower

I have a JS Query that runs when a user clicks an item in my list to add the part to a cart prity much. After adding a larger qty of items the clicking starts to lag due to the query slowing down. After it got slow I commented out my whole js code and only had a console.log("ran query") line in it, and after each run, the time still increases. With just the console.log statement it increases by 60-90 ms each run. With my regular js code, it will usually add 180 - 250 ms per each run.

Is there some cached data that is adding up making it slower on retool side?

Screenshot 2024-03-18 at 4.57.32 PM

Hi @PadenM, we would love to see the JS query so we can have a better grasp on what's going on and how to improve it.

Here is my js Query @Paulo

I am selecting a part from a list to add to my restock order. It adds the item into a seperate array and also updates a key field of "added" so you can see in the list that you have already added that item to your restock order. I also have a temp_array to be able to use with some stepper input fields. I have to use a seperate array for the UI to be smooth or else it gets super choppy with while the user updates it.

Screenshot 2024-03-25 at 2.33.39 PM

I don't see anything obvious that may be making this slower overtime, specially knowing that it becomes slower even if you just have a console.log instead of all the JS. Could you attach a screen recording? Feel free to use loom, or another TPA if you can't attach it here.

Here is a video. One thing i do have is transformer that runs to get my filtered list of parts. Not sure why it would increase to the latency... but it is there and seems to runs each time as well.

Screenshot 2024-03-25 at 6.46.41 PM

Thank you for sharing the video. It looks like the queries are only taking a couple of seconds. The accumulative time it's showing might be a bug.

Is "filtered_master_parts" running every time we make a selection? Or are those runs from typing each character on the text input? The data should be filtered to render the index of parts after the user is done typing on the input, but we should not be running this after every click, that may be the reason why the app is slowing down. We can fix this by adding an "On change" event handler to the text input that runs the filter JS query.

I ended up just removing a piece of the code that updates the list of parts by editing the key "added" and that helped out. I wanted to edit the parts list to see what i had already added but the performance on it was poor. I have noticed that updating variables affects the performance a lot on the mobile apps.
Thanks for the help

A workaround for this could be showing details of the added part in the notification. Since it's single reference, it should not slow it down the same way that updating components within the List View does.