I’m working on a sample app to show filtered data from a Google sheet in a Data Viewer List, specifically to show either all Foreign Language Oscar nominees, or only those in Spanish.
My strategy is to bind a local Thunkable sheet to the Data Viewer List, and then programmatically place either all rows of the Google sheet into it, or selected ones.
The app works, sometimes. But other times it is slow and the data doesn’t appear either at all or just partially. This is true whether it is in web preview or on my phone.
I suspect this is an asynchronous call problem. You’re trusting that app variable idList is actually populated before you call viewAll.
You’re also assuming that the loop is going to finish before it runs a second time. You’ve got asynchronous calls in there, so that’s not guaranteed, so your ‘film’ variable may not be the value you’re expecting.
If you add a wait of a second (or even a 10th of a second) in that loop, does the problem disappear?
Thank you @catsarisky for the ideas. I wasn’t thinking of the asynchronous nature of some blocks. I did try the “wait” and still having issues, but I’ll play around some more
If you have time and are interested, I have a couple of questions:
when you call a function that doesn’t have a “do”, e.g., “list of values in a column”, can you assume it is synchronous, i.e., it will complete before the next row is executed? That was my understanding but not sure.
Is the “temporary” sheet to hold filtered data so you can map it to a Data Viewer List the best way to show filtered data?
In the example is based on two local tables but I tested it with the main table from Airtable and the one bound to the DVL is local.
To answer you questions:
Although it seems sequential but it is actually asynch in nature but from my tests it takes nearly the time of retrieving a single record. Due to this short period of time it acts as close as possible to a sequential block.
If you chose a DVL then you have to connect it to a table and currently there is no filter function in Thunkable so you are left with this choice.
I used cloning to get rid of committing to the local table and it works well but unfortunately the DnD UI does not have the clone nor the copy block and therefore you will be restricted to the old UI.
As you’ve had success with airtable/local and local/local, perhaps it is google sheets that is causing the issue (maybe only handles so many hits, or just times out). I’ll try my sample with airtable/local
asynch/synch: seems weird that you cannot count on sequentiality when you make a call to a function without a “do”, but I think you’re right. Thunk team, is this correct? Is the ultimate goal to rectify this?
can you explain your use of cloning to avoid committing to local table? I don’t know what you mean and don’t see in your sample
Thanks so much, I wasn’t aware you could dynamically create components like that.
I guess the ideal would be for Thunkable to add a method of mapping Data Viewer List to a list of objects (though I realize object properties are dynamic and spreadsheet columns aren’t really)
Interesting that even on a function, clone, with a “do”, you still had to put the wait. It seems like you should be guaranteed sequentiality in the “do”, as well as for call blocks that don’t have a “do”