Store a state (Like Button)

Need help
1

Hi there,

I am building a webapp where users will be able to like pages.

The like button works fine (color of the icon is changing when a user like/unlike and a counter displays the number of likes when a user click on the icon (+1/-1))

However when i leave the page and come back, the like button is reset and I can like another time the page.

Is there a way to save “the state” of the like button in order to avoid unlimited likes ?

Thanks a lot for your ideas or feedbacks :slight_smile:

2

Store the like in your database

1 Like
3

States only exist on the page, and are reset anytime the page is reloaded…

To save something more permanently you’ll need to save it to the database.

Alternatively you could set a cookie on the User’s browser to store the data…

But, generally, for ‘likes’ the database is where you’ll want to store them.

2 Likes
4

Thanks and thanks @mac2 for your feebacks.

Likes are already stored in my DB.

Please find below more détails :

  • i have a data called “créations”
  • i have a field in that table (type number) called “Likes”
  • Every Time a user click on the “Like icon” on the page “création” the amount of likes increase or decrease and the icon change (black when not cliked ans become red when user click once and go back to black when user click again to unlike)

It may Come of my Datastracture or my Logic which are wrong ? What do you think ?

5

I’m interested in what others have to say on this as well.

I’ve implemented “liking” on my web application but I’ve restricted it to just logged in users. I have heard things about allowing guest users to vote and something about Bubble putting a 3-day cookie on their browser but wasn’t sure if that meant after 3 days the like count would go do down by 1 and just didn’t take the time to fully look into it.

Personally, I’d love to be able to allow it so that guests can “like” something and Bubble then saves their IP address to a field. So then later if that user goes to “like” an object, Bubble first checks the DB to see if that IP address exists.

I’m sure there is something like this already, I just haven’t looked into it heavily.

1 Like
6

I’m not sure if there’s a downside to this approach, but instead of storing the likes as a number, store it as a list of Users called “Liked By” or something. Then when they press like have it add the current user to the list. If you need to show the number of likes just to the Things’s Liked By:count

For your black like button indicating it’s not liked, have it only visible if the current pages’ LikedBy users doesn’t contain Current User. For the workflow make changes to a thing, current pages thing’s LikedUsers, add current user. Then make another red like button indicating it’s liked, and do the opposite for the workflows. It can also be one button but use conditionals to change the color of the icon, and conditionals on the workflows so only one or the other runs.

1 Like
7

The way I suggested also helps later on, because if you want to go to the users profile and see everything they have liked, just do a repeating group, data source would be Do a search for Thing, and one of the constraints being Liked By contains Current pages user

1 Like
8

So how are you storing whether a user has liked a creation or not? (hint… you’re not at the moment, and you need to be…)

Although it can be a good idea to store a number field for total likes, you also need a way to store the actual ‘like’… (I.e, who has like what)

One way to dot that is to store a list of users who have liked a particular thing.

Anothe way is to store a list of things that a particular user has liked.

Both of those are viable options, but from a performance stand ping not optimal (not Tom mention that lists have a hard limit of 10,000 items).

A third, and generally more scalable option is to create a separate datatype for ‘likes’ which connect a User to a Creation. This is generally the best approach for this type of thing.

The Bubble manual does a good job of explaining the pros and cons of the different methods, and has some example use cases, so I’d suggest having a read of that first…

1 Like
9

Following up on storing users. I’m currently recording BOTH the # of likes AND the list of users, but I’m concerned it’s redundant. The workflow basically looks like:

When “Like Icon” is clicked > add +1 to the “Likes” field > add current user to “Users who liked” list."

The count displayed used to pull from the # of likes field, but now I just do a :count function to show the number of people that are on the list.

I’m guessing the initial “# of likes” field is no longer needed?

1 Like
10

You don’t need it, but it’s better to have it - it will be much faster to display the number of likes from that field than it will by doing a count, plus you’ll be able to use it for sorting, which you won’t be able to do with the count of like.

2 Likes
11

Oh I didn’t realize that! So glad I asked then! Next on my roadmap is to add a sort for showing objects with the most/least likes. Very good to know!

1 Like
12

Thanks and thanks @adamhholmes and @brandon8 for your contributions. Really appreciate.

Indeed i do not store at the moment the creations that users liked. I’ll try that for sure.

And thanks @adamhholmes for the reminder about the limit of 10,000 items for lists… I have 800 users on the current version of my project (https://webrief.fr/) running on a custom Wordpress so it does not seem to be an issue right now :see_no_evil:

I tried to separate my datas most of the time (for ig : i have a data for “category” which is connected to other another data called “brief” and “creations”). So i’ll also try to separate the “Likes” and connect them to creations.

I am ok with UI design and front-end developpment but less with DB structure and backend…I have to work on it…

I’ll come back to you soon :slight_smile:

Thanks a lot again

1 Like
13

This topic was automatically closed after 70 days. New replies are no longer allowed.