My App/Pages Support link:
https://go.glideapps.com/support/2c0522e1-9857-4fac-97f7-abc6d40b645b
Describe the bug:
I have a look up of a user ID’s ‘liked’ listings. The linked listings show up for a second and then disappear. when I click through different user views this happens for all of them
Expected Behaviour:
The linked listings should remain and be able to be used within an inline list
How to replicate:
In the ‘matches’ table, scroll sideways to the end of the rows until you see a lookup called ‘opposite likes’, and then click between users in the drop-down and you’ll see the listings show up for a second and then disappear
Demonstration:
1 Like
Does it affect the components/columns that you use on top of that lookup column?
If you mean creating a list component from this, yes, it shows up nothing
1 Like
Oh I thought posting a bug here was sending it to the team! I’ll send it via that link too - cheers
It’s always a good idea to post here first, as there may be others that have the same issue, and there could be known workarounds. And sometimes what we think is a bug turns out not to be one at all 
But ultimately, if it’s a bug that needs to be fixed then it needs to get to the Glide engineering team. Often they’ll pick things up from here, but that’s not guaranteed. The “official” path is via the support link that Thinh gave you.
3 Likes
How exactly are you trying to use a lookup column in a list component? It looks like you have a multiple relation, meaning the resulting lookup is an array of multiple values, which means you can’t use it for any of the single value containers inside any of the list items.
Hey Jeff, does this mean a look-up can’t create a list of different things, it can only be viewed as a single object? If this is the case I would expect the inline component to not be able to be driven from it, and it not show separate objects?
If you are trying to create a list from a lookup column, that’s not going to work. A lookup returns either a single value or an array of multiple values from a single column. A list is based on rows. If you are trying to add an inline list then it really should be referring to the relation column instead. A relation returns rows and a lookup returns a single column from that relation or table.
4 Likes
I’m afraid it’s the same problem with a relation. I wonder if it’s because the user ID is coming from an ‘if this than that’?
Coming in late here, but my gut feeling is that there might be a simple solution.
Any chance you can make a video and talk us though the steps that lead to the creation of the lookup in question, and then show how you’re wanting to use it?
4 Likes
Thanks Darren, i’ve made a video showing how I got to where I am at the moment. I got some feedback earlier from customer support saying that the issue is related to the ‘likes’ being personal to the liker so others can’t see what they liked, but I’ve done things like this before and its worked, so I don’t really know what’s happening. Loom | Free Screen & Video Recording Software
One other thing. in relation to the ‘matching’ of the listings in the tinder-style, a lot of confusion arises when trying to create the ‘match’ table and show who’s who in the match. Currently is shows as ‘user 1’ and ‘user 2’ and I’ve had to do and ‘if this than that’ to pull out the opposite users ID… a bit of a mess
I think I agree with Glide Support. The problem is that the Liker column in your Listings table is user specific. So each user will only see their own data in that column. This is evident in your video, where you’re viewing as Tasmin, and only her email is present in that column. If you switched to a different user, I’d expect that you see something completely different in that column.
To get around this, you need to get your Liker ID’s into a basic column that all users can see. What I’d probably do is use a simplified variation of the trebuchet method, where you create a comma separated list of Liker ID’s in a basic (not user specific) text column. Once you have that, you can run it through a split text column and use that to build the relation that you need.
So when a user likes an item, you need an extra action that adds their ID to the list of Likers. I haven’t done this for a while, but off the top of my head it goes something like this:
- You have a template column in your Listings table that takes the current contents of the Likers column, and adds a comma, followed by the current users ID
- You then have an if-then-else column:
– If Likers is empty, then current users ID
– Else template column
- Then when the user “likes” an item, you do a Set Column Values on the Likers column (the list of users), setting its value to that of the if-then-else column
Give that a try…
3 Likes
Wouldn’t it be easier to just maintain a sheet of all positive swipes and then create a relation?
In that way , in future you can hide the elements from swipe that i have reacted in a positive way!
Correct me if i am wrong!
Yes, that would work, and that’s a more traditional way to do it. But it’s a lot more expensive in terms of row count. Which is often an issue when it comes to Glide apps.
1 Like
does the row count slow down the product, or just cost more? (I’m ok with the latter)
It depends.
Using the joined list approach, you will only ever have one row for each item in your listings table.
Using the alternative approach that @ShantanuIyengar suggested, you’ll have an extra row created for every positive swipe on every item.
So it depends how many users, how many items, and how many positive swipes. But it could very quickly add up to a lot of rows.
If we had actions based on data matching (rather than clicking) I’d be able to make the matches from this list too! I do currently have a list of positive swipes, and I’m looking at using this for the issue in the video (good idea!) - would be awesome if it could in someway become the match too, but can’t see the logic yet
What if simultaneously two of them clicked on it!
Screen data is actually cached on the user end.
So if two people are on the same screen and they do the action! Its going to overwrite the data and the last one to do it would be added to likes!
Possibility is slim, no doubt!
1 Like
Yes, that’s true. The approach is subject to a concurrency issue, and I’ve actually seen this issue in apps that have high volume usage. If that became an issue, there is a workaround, but it involves delegating the column updates to a 3rd party.
But, as you say, it’s an edge case that’s very unlikely unless you have two or more users liking the same item at almost precisely the same time (within a few seconds).
2 Likes