Restaurant menu as uber

Hello, after trying several things to create an uber menu I managed to have a result but slow.

A data viewer list for the menu linked to an Airtable.
Then another data viewer list linked to a local table that is filled with information from firebase.
When you click on a menu, I will look for the customizable items of this menu in firebase I insert them in a local table to load them on the data viewer list.

But thunkable takes a long time to fill the local table with firebase information and then display it on the data viewer list.

But at this moment it’s the fastest way I found.
Because in reality I need a page with all the menus, then another page with the customization of these menus, but I don’t want to create 50 screens for the 50 different menus to be able to set the parameters in the data viewer list.
I wanted something dynamic that can be modified outside the application.

So I end up with a 2000 block screen that takes 30 to 90 seconds to load the menus.

Much too long for a user.

What could be good is to be able to modify the parameters of the data viewer list directly from the blocks like the Table, the layouts, the data bindings.

Do you have a solution other than mine to make a dynamic restaurant menu with 2 steps ?
Choice of menu > Choice of ingredients,burgers,drinks and quantity > validate

Thanks

1 Like

There are some known reasons that data retrieval or storage may take a long time, especially with Firebase. If you post a link to your project or screenshots of your blocks, we can provide some suggestions for speeding things up.

1 Like

I could provide a link to the project but it would take a lot of time to understand because there are 2000 blocks on the page, namely I retrieve from firebase the raw JSON to speed up the thing.

1 Like

My experience is that as you exceed 500 block on a screen performance really deteriorates. Loops are also very, very slow. Consider building a server side process for you menu so thunkable can simply display pre-organized/formatted data.

2 Likes

Can you show the data retrieval part and the data selection/filtering part?

1 Like

Yes, this. As I said, there are known, reproducible issues that will slow down what you’re doing. Things like using stored variables instead of app variables or the difference between using Realtime DB blocks vs. cloud variable blocks when referencing Firebase nodes.

1 Like

Hi, Thank you all for your answers

Here is how I get the firebase data.
The menu variable stores the raw JSON of all the menus

Then in the variable data.fire I store only the menu I want using the variable selection.edit which contains the name of the menu I want

I then do the filtering in the loops to store the data in the edition variable correctly.


And finally I create the columns in the local table with the corresponding values to then display it on a data viewer list.

The problem is that on android it’s very slow, I know that the best way to have something that loads fast is to use a data viewer list. On Iphone it takes 10 seconds, on android it takes 60 seconds.

1 Like

Wow… This really really takes resources and a lot of time.

You know if you load your database in a chargeable cloud, usually by hits, this routine will cost you a lot.

How many times this function is supposed to be called within a normal use of the app?

1 Like

The JSON block with all the menus is retrieved only if one of the menus is updated by the admin, then the version of the menu changes and it will be loaded when opening the application.
The json is stored as a local variable as long as the version doesn’t change, I could optimize instead of reloading the whole json block only modify the menu that has been modified by the admin.
But what I’m really interested in is to save time by displaying the menu for now.

If thunkable would add a block in the data viewer list that would allow to switch from airtable page or google sheet and to set the data bindings it would be an exploit

1 Like

One thing to note. Reading from a database is obtaining data from a source external to the app which makes it slower than the variables within the app. However, a stored variable is also an external source and is as slow as reading from the tables.

Secondly, you are using too many variables and a loop inside a loop inside a loop which I know you have a reason for it but sometimes if you look back an think of redesign your data structure you will have less complicated procedures to gather the data the way you want it.

I cannot comment more as most of the variables are referenced here but do not know where to take their initial values. If the values are coming from the stored variable then this will introduce a level of delay.

2 Likes

Yes the external data are the menu that can change. And if I call stored variable it is for reasons of moves and avoid unnecessary calls to a database.

  1. Alas the loop is to restructure the JSON data because at the base I have a raw json code and to filter it and place it in the right place.

I’ve already tried 5 different ways to restructure the data to get the result I want and I’ve already deleted 5 times the way to do it starting from 0.

I think it’s impossible to reproduce an uber type menu on Thunkable.

If also thunkable would allow to save the local tables then to load them that would change all, I am limited technically

Thanks for your time

2 Likes