[bug] Like/Boost indicator disappears after a few moments #370

Open
opened 2024-02-12 23:20:04 +00:00 by Oneric · 0 comments
Member

Version

d304be654f

What were you trying to do and what went wrong?

Had this issue and the first research results here noted down for a while, but didn’t get around to look into how to fix this with the various event dispatches and layers involved here; before I forget i’ll post my findings so far here. Ofc anyone is welcome to to tackle this.

Sometimes when i fav or boost a post, the icon first performs the animation into an activated state but then after a few moments the indicator disappears again. Reloading the page brings the indication back.

Looking through the code it seems like when the button is clicked, the fav/boost is immediately added to the local data and the state activated and at the same time requests to both actually submit the action to the server and to refetch the current number and accounts who faved/boosted the post are submitted.

I’m guessing sometimes the refetch gets processed before the actual action, so when the reply arrives the own action isn’t accounted for yet and subsequently the indicator toggles off again.

Relevant parts of the code:
8dce31d0ad/src/components/favorite_button/favorite_button.js (L21-L31)

    favorite () {
      if (!this.status.favorited) {
        this.$store.dispatch('favorite', { id: this.status.id })
      } else {
        this.$store.dispatch('unfavorite', { id: this.status.id })
      }
      this.animated = true
      setTimeout(() => {
        this.animated = false
      }, 500)
    }

8dce31d0ad/src/modules/statuses.js (L279-L286)
Note how it directly adds the own fav to local data; in itself this isn’t necessarily a bad idea as it improves UI responsiveness on slow network — as long as a failure is later properly indicated and a success doesn’t just randomly disappear again

    'favorite': (favorite) => {
      // Only update if this is a new favorite.
      // Ignore our own favorites because we get info about likes as response to like request
      if (!state.favorites.has(favorite.id)) {
        state.favorites.add(favorite.id)
        favoriteStatus(favorite)
      }
    },

8dce31d0ad/src/components/status/status.js (L543-L548)

    'status.fave_num': function (num) {
      // refetch favs when fave_num is changed in any way
      if (this.isFocused && this.statusFromGlobalRepository.favoritedBy && this.statusFromGlobalRepository.favoritedBy.length !== num) {
        this.$store.dispatch('fetchFavs', this.status.id)
      }
    },

What did you expect to happen?

Indicator never disappears once activated unless there was an actual issue submitting the action to the server.
I.e.: fetching the new fav/boost count and users should wait until after the initial favourite/boost request finished.

Severity

I can manage

Have you searched for this issue?

  • I have double-checked and have not found this issue mentioned anywhere.
### Version d304be654f4538c3b61b9e017f59cc33bab142ed ### What were you trying to do and what went wrong? Had this issue and the first research results here noted down for a while, but didn’t get around to look into how to fix this with the various event dispatches and layers involved here; before I forget i’ll post my findings so far here. Ofc anyone is welcome to to tackle this. Sometimes when i fav or boost a post, the icon first performs the animation into an activated state but then after a few moments the indicator disappears again. Reloading the page brings the indication back. Looking through the code it seems like when the button is clicked, the fav/boost is immediately added to the local data and the state activated and _at the same time_ requests to both actually submit the action to the server and to refetch the current number and accounts who faved/boosted the post are submitted. I’m guessing sometimes the refetch gets processed before the actual action, so when the reply arrives the own action isn’t accounted for yet and subsequently the indicator toggles off again. Relevant parts of the code: https://akkoma.dev/AkkomaGang/akkoma-fe/src/commit/8dce31d0ad53a5bcce9cc42f192ddada26e848a2/src/components/favorite_button/favorite_button.js#L21-L31 ```js favorite () { if (!this.status.favorited) { this.$store.dispatch('favorite', { id: this.status.id }) } else { this.$store.dispatch('unfavorite', { id: this.status.id }) } this.animated = true setTimeout(() => { this.animated = false }, 500) } ``` https://akkoma.dev/AkkomaGang/akkoma-fe/src/commit/8dce31d0ad53a5bcce9cc42f192ddada26e848a2/src/modules/statuses.js#L279-L286 Note how it directly adds the own fav to local data; in itself this isn’t necessarily a bad idea as it improves UI responsiveness on slow network — as long as a failure is later properly indicated and a success doesn’t just randomly disappear again ```js 'favorite': (favorite) => { // Only update if this is a new favorite. // Ignore our own favorites because we get info about likes as response to like request if (!state.favorites.has(favorite.id)) { state.favorites.add(favorite.id) favoriteStatus(favorite) } }, ``` https://akkoma.dev/AkkomaGang/akkoma-fe/src/commit/8dce31d0ad53a5bcce9cc42f192ddada26e848a2/src/components/status/status.js#L543-L548 ```js 'status.fave_num': function (num) { // refetch favs when fave_num is changed in any way if (this.isFocused && this.statusFromGlobalRepository.favoritedBy && this.statusFromGlobalRepository.favoritedBy.length !== num) { this.$store.dispatch('fetchFavs', this.status.id) } }, ``` ### What did you expect to happen? Indicator never disappears once activated unless there was an actual issue submitting the action to the server. I.e.: fetching the new fav/boost count and users should wait until _after_ the initial favourite/boost request finished. ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.
Mergan added the
Bug
label 2024-03-01 03:38:52 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma-fe#370
No description provided.