As we all know, data sources have mouth-watering potential. Reading data sources seems stable with acceptable performance (if approached correctly). At the time of this writing, the CUD of CRUD (Create, Update, Delete) of data sources, as well as binding to viewers, leaves something to be desired…
While we wait for the bleeeding-edge of Thunkability to stabilize, I would like to pose the following question:
What can be done with data sources and Data Viewers that cannot be done with JSON and Cloned Components?
Admittedly, using JSON and cloned components requires a LOT more blocks. But I am asking with a purpose. If experienced Thunkers can list specific capabilities of Data Sources and Data Viewers which are NOT possible with JSON and clones, I would like to build functions that can address those issues while the great team a Thunkable perfects their components. I think this will also help the Thukable staff better understand Thunker needs and goals.
Again, I’m not looking for a gripe list, but rather a list of features we need to make Thunkable development faster, easier, and more enjoyable for everyone!
Great question! I came to Thunkable because of its integration with AirTable and Google Sheets. The tool I had been using was more advanced in terms of layout and sprite manipulation but it didn’t have any way to connect to databases. And I’m all about databases.
I like the idea of cloned components. It makes everything SO efficient. But… cloning and getting data is really slow. I had made an app – my first major attempt with Thunkable – that pulls the names of students from AirTable and displays them in a 5x5 grid (25 students). It was slow to update, taking as much as 5 seconds to refresh the screen each time. The version in the other tool was instantaneous but used a local data source.
I haven’t tried your method of using JSON objects yet. I suspect it’s the real deal! But what I had trouble with was scrolling cloned components. I made a loop (ah, loops, something else that needs to improve in Thunkable) that clones a row for each row in a database. If I have it clone the row 10 times and delete the original, I expect to have 10 rows and to be able to scroll up and down to see them. But however many rows I choose to clone, I can only see about 1/2 of them. The rest are missing from the scrollable area. So unless there’s a fix for that, I can’t see using cloned components for something with a dynamic height and number of items.
I’m also curious about how you refresh the cloned data with JSON. With a custom data viewer list, I have been able to get the data itself to update but not to delete (e.g. if I delete all of the rows in the data source, the viewer retains all of the displayed info). I realize I went on a bit of a tangent here… sorry!
Yes, the data source query blocks are very slow. I came up with a bit of a hack [Data Source Performance Workaround FOUND!]. Performance is one of the reasons I use firebase realtime. The read/write times are incredibly fast and reliable (it is just text).
When cloning, which element you clone and where it is cloned are critical and unforgiving :-(.
From my remix project (Create Horizontal Scroll (Swipe Like) Row - #27 by drted), notice that the Scroll templates (the boxes with the actual data) are cloned one after the other in the same container. But the real trick is to clone the Master Column (not the scrolling column) and place it at the next-to-last element in the screen. The solution is definitely a russian-doll kind of layout with containers in containers in containers.
To show changes in the source data, I delete the cloned elements by looping through the appropriate container. Usually I just delete all of the cloned “Master Columns” then rebuild everything from scratch. I’ve played around with updating individual labels using and x/y cooridate system to refer the appropriate containers, but it was a very brittle screen. Sometimes I will cheat a little and add a label or button with some hidden text. Then I can loop through all of the compnents in the screen until I find the hidden text, then use that as a anchor for updating adjacent components. Again, pretty high maintenance, but it does provide better performance. But for most situations delete clones and rebuild sticks to K-I-S
