"Like" button performance and sync issue

Hi All,

I added a “Like” feature on table A that contains a library of activities. To do so, I simply created a mapping table between table A and the user table B.

On table A, I added a virtual field Y/N to check if it is a liked record by the current user:

This is clearly terrible in term of performance. Any alternative?

I then added a format rule to display the heart icon when the record is liked.

The problem is that the heart icons are displayed correctly only the first time I load the page A. Once I navigate and come back to it, they are gone. I need to refresh the app to get them back.


@MultiTech_Visions haha, we were just talking about this!


If card likes has a security filter on it so that only that users USEREMAIL() is present. And the card like table has a REF back to card… Then you could just be able to count the already created virtual column REFROWS…

1 Like

So, you wouldn’t even need the yes/no virtual column. Just count the REFROWs to know if you should show the heart, or which action to take…


I suggest that the simpler way which will not involve another tables, but far more simpler and powerful way.

I created sample for you and the community.


I will place this to “tips and tricks” category with new thread.


The problem with this setup is something that @Grant_Stead and I were talking about earlier this week.

What happens when I open your app on a Friday… And I find something that I intend to like. But suddenly, life happens and I forget all about everything that was happening, but I don’t close the app. Say I get a phone call, then I have to go rush off and do something else… All the weekend happens… But I haven’t shut the app, it’s sitting open in my phone in the background, I just haven’t dealt with it yet.

then I remember, on Monday morning, that I was going to go back and do that stuff in the app. So I open the app, which doesn’t reload or anything because it’s just been sitting in the background of my phone, and then I like the thing - which then gets uploaded into the cloud updating the row.

Meanwhile, between the time when I opened the app and when I hit the like button, 200 people have also done the very same thing.

Do you see the problem…

since my app is using older data, when I make my modification and it’s sent to the cloud, my modification wins; and all of those 200 people that made modifications to that row over the weekend, they’re all lost.

This is because you have multiple users modifying the same row, and with app sheet and the asynchronicity of it, the last person wins… no matter how old their data is.

instead of making it to where the person directly modifies the row, you need to make it to where the row will update itself and find who is inside the group or not. And the only way to accomplish this, with the asynchronicity of AppSheet and to not have any kind of lost data, is to integrate another table.


^^^ When the system evolves, and you evolve with it.

1 Like