Does everyone else have “favoriting” functionality in their apps and notice that the app stalls when you like 2 or more items consecutively? Would appreciate any solutions.
Dear, I can help you fix the problem, please schedule a meeting here to proceed: Calendly - Asynk Tech
1 Like
Thanks, I’ve scheduled time. Talk soon.
While I wait, does anyone have recommendations?
Hi @Emeka,
In general, Adalo isn’t that good in creating “Favourites” in large-sized collections.
To start with, there are 2 possible approaches how to create favourites. First one is creating many-to-many relationship between 2 collections (e.g. Users and Items), so that User can like many Items and Item can be liked by many Users.
To Like an item, you can use simple Toggle element.
This approach works, however it will work slower and slower with growing collection size (1000s of records) and number of “likes”.
Another approach is to create a “Junction table”, which will store the “likes” themselves: one Like can belong only to one User and to one Item, and both of other collections have many Likes. Similar approach is described here Adalo Mini-app series: Followers, Influencers and follow requests - using separate collection - YouTube (it is for Followers but could be adapted to Likes).
This approach usually works faster, however, it has some drawbacks:
- there is a complexity related to “unliking” the item. If you’d like to remove like, you need to remove the item from the Likes collection; for this you need either to create a list inside the list (which will be slow with large number of items), or create a separate page with the single-item list of Likes for current Item and User;
- there is a potential risk of creating several “likes” records if the connection or app is slow;
- and this approach also starts working slower with growing collection size.
Here I was talking about pure Adalo approach, without any external components / collections. The major issue with speed is caused by the fact that Adao app needs to send the data to the backend server, receive a response and then display update on a page (e.g. change toggle). As you can imagine this takes time, and along with the database size growth responses might become slower.
A good workaround could be some custom icon component which displays the change before sending/receiving data from backend server. Visually this will look much better for a user. However I’m not aware if such component exist (although I remember some talks about it).
Hope this explains how things work a bit 
Best regards, Victor.
1 Like
@Victor – as always, thank you for the in-depth expert-level guidance. You’ve got the forums and Youtube covered. Okay, it seems the alternate path has a lot of downsides and is more complex.
Exploring the “custom icon component” you mentioned, are you referring to a two-image button that mimics a toggle? When the user presses the image, the second hidden image, “fake toggle”, becomes visible, and the liking/unliking is done on the backend while not impacting the speed of subsequent image/toggle changes. Would something like that work?
Thank you.
Yes, you’ve got my idea. I believe that such custom component could be developed.
Out of curiosity I tried to mimic such functionality with conditional visibility stored in input + timer to fire the update action and it even worked, but of course this is not something which can be used in production.
By the way when I tested Supabase and presented the Items + Favourites tables to Adalo in a single view (in Supabase it will be a join tables query), favouriting / unfavouriting worked pretty stable, with ~1 second delay. The downside was that I had to write a custom action to perform this change.
Summing it up - I’d start with exploring the custom component path
Best regards, Victor.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.