pleroma/pleroma-fe
Watch
2
2
Fork
You've already forked pleroma-fe
 10
Code Issues 351 Pull requests 26 Projects Releases 5 Packages 1 Wiki Activity

Bookmarks #2170

Closed
eugenijm wants to merge 5 commits from gitlab-mr-iid-903 into develop
pull from: gitlab-mr-iid-903
merge into: pleroma:develop
Conversation 33 Commits 5 Files changed 20 +213 -24
eugenijm commented 2019-08-05 11:25:27 +00:00
Member
Copy link

Revives the bookmarks MR (Closes #472).

  • pagination needs to be updated to be compatible with the current BE implementation, which stores bookmarks in a separate table in the DB (ref: #667).
Revives [the bookmarks MR](https://git.pleroma.social/pleroma/pleroma-fe/pulls/2021) (Closes #472). - [x] pagination needs to be updated to be compatible with the current BE implementation, which stores bookmarks in a separate table in the DB (ref: https://git.pleroma.social/pleroma/pleroma-fe/issues/667).
kaniini commented 2019-11-08 01:32:39 +00:00
Member
Copy link

Please update the pagination and resolve the WIP status and I will test and review it.

Please update the pagination and resolve the WIP status and I will test and review it.
eugenijm commented 2019-11-15 13:38:45 +00:00
Author
Member
Copy link

Done, ready for review

Done, ready for review
hj commented 2019-11-19 17:12:22 +00:00
Member
Copy link

what is that and why is it needed

what is that and why is it needed
hj commented 2019-11-19 17:16:29 +00:00
Member
Copy link
      return this.status.bookmarked ? 'icon-bookmark' : 'icon-bookmark-empty'
```suggestion:-0+3 return this.status.bookmarked ? 'icon-bookmark' : 'icon-bookmark-empty' ```
hj commented 2019-11-19 17:17:39 +00:00
Member
Copy link

doesn't belong here, i doubt people will use it often so it's better in three-dots menu instead

doesn't belong here, i doubt people will use it often so it's better in three-dots menu instead
hj commented 2019-11-19 17:20:18 +00:00
Member
Copy link
  // Note: BE doesn't order bookmarks by their status ids and doing so here would break pagination.
```suggestion:-0+0 // Note: BE doesn't order bookmarks by their status ids and doing so here would break pagination. ```
hj commented 2019-11-19 17:24:23 +00:00
Member
Copy link

not liking the "meta" name... how about we use preserveOrder boolean that will disable sorting (also removes ugly timeline !== 'bookmarks') and forces it to use maxId/minId from array's head and tail instead of minBy/maxBy

not liking the "meta" name... how about we use `preserveOrder` boolean that will disable sorting (also removes ugly `timeline !== 'bookmarks'`) and forces it to use maxId/minId from array's head and tail instead of minBy/maxBy
hj commented 2019-11-19 17:26:51 +00:00
Member
Copy link

report error in console?

report error in console?
eugenijm commented 2019-11-20 13:13:43 +00:00
Author
Member
Copy link

On BE, bookmarks are represented by a different table, and their ids are only available via the Link header (https://web.archive.org/web/20191119161310/https://docs.joinmastodon.org/api/rest/statuses/#pagination). The http-link-header lib is for parsing it.

EDIT: Mastodon broke the link

On BE, bookmarks are represented by a different table, and their ids are only available via the Link header (https://web.archive.org/web/20191119161310/https://docs.joinmastodon.org/api/rest/statuses/#pagination). The `http-link-header` lib is for parsing it. EDIT: Mastodon broke the link
eugenijm commented 2019-11-20 13:59:11 +00:00
Author
Member
Copy link

We still need maxId/minId from the Link header because they are referring to a different table which represents bookmarks on BE. The good thing is that having prev/next page in the Link header is a part of Mastodon TL API and so we don't have to introduce special case. But we still need to pass the ids from apiService.fetchTimeline to addNewStatuses to make use of them; I'm not sure if there is a way to avoid it without affecting the bookmarks TL.

We still need maxId/minId from the Link header because they are referring to a different table which represents bookmarks on BE. The good thing is that having prev/next page in the Link header is a part of Mastodon TL API and so we don't have to introduce special case. But we still need to pass the ids from `apiService.fetchTimeline` to `addNewStatuses` to make use of them; I'm not sure if there is a way to avoid it without affecting the bookmarks TL.
feld commented 2019-11-27 15:40:30 +00:00
Owner
Copy link

Are we bookmark ready yet?

Are we bookmark ready yet?
vaartis commented 2020-01-29 08:24:09 +00:00
Member
Copy link

What's the status on this? May I take over and finish it?

What's the status on this? May I take over and finish it?
hj commented 2020-01-29 11:23:27 +00:00
Member
Copy link

i need to re-check it and test it, basically

i need to re-check it and test it, basically
vaartis commented 2020-01-29 12:07:13 +00:00
Member
Copy link

Now that there are emoji reactions, the UI probably needs to be changed a bit..

Now that there are emoji reactions, the UI probably needs to be changed a bit..
lanodan commented 2020-02-05 16:56:54 +00:00
First-time contributor
Copy link

Shouldn't this also be present for other ~timelines? The bookmark pagination isn't really that specific other than with the ordering that needs to be preserved.

Shouldn't this also be present for other ~timelines? The bookmark pagination isn't really that specific other than with the ordering that needs to be preserved.
eugenijm commented 2020-02-05 21:00:44 +00:00
Author
Member
Copy link

Right now, the prev/next ids are taken from the status list from the response body by calculating min/max status ids. This doesn't work for bookmarks since /api/v1/bookmarks returns a list of statuses, and their ids cannot be used for paginating bookmarks (but link headers containing bookmarks ids can).

In the MR, the change applies to other timelines too for consistency (prev/next ids are taken from link headers instead of status list from the response body).

Right now, the prev/next ids are taken from the status list from the response body by calculating min/max status ids. This doesn't work for bookmarks since `/api/v1/bookmarks` returns a list of statuses, and their ids cannot be used for paginating bookmarks (but link headers containing bookmarks ids can). In the MR, the change applies to other timelines too for consistency (prev/next ids are taken from link headers instead of status list from the response body).
hj commented 2020-02-06 09:40:54 +00:00
Member
Copy link

the change applies to other timelines too for consistency

thanks for mentioning, that's something that needs to be tested also.

>the change applies to other timelines too for consistency thanks for mentioning, that's something that needs to be tested also.
shpuld commented 2020-06-27 07:58:20 +00:00
Member
Copy link

we used this for the exact same purpose in pleroma-api: https://bundlephobia.com/result?p=parse-link-header@1.0.1

about 3 times smaller

we used this for the exact same purpose in pleroma-api: https://bundlephobia.com/result?p=parse-link-header@1.0.1 about 3 times smaller
shpuld commented 2020-06-27 08:45:46 +00:00
Member
Copy link

The pagination implementation itself seems to work right on timelines

The pagination implementation itself seems to work right on timelines
shpuld commented 2020-06-30 06:10:57 +00:00
Member
Copy link

what's going on in here? this breaks the public timeline icon (zoom-in and users icon have the same code, so the public timeline icon is replaced by the zoom-in icon)

what's going on in here? this breaks the public timeline icon (zoom-in and users icon have the same code, so the public timeline icon is replaced by the zoom-in icon)
eugenijm commented 2020-06-30 07:53:14 +00:00
Author
Member
Copy link

that must be a rebase leftover, sorry, fixed it

that must be a rebase leftover, sorry, fixed it
shpuld commented 2020-07-03 12:31:34 +00:00
Member
Copy link

I did some more testing, just observing the same timeline on this branch and on my instance without it, for some reason in this branch it triggers the timeline "flush" much more often for no good reason. on my twkn it went from "Show new (6)" on both tabs to "Show new (8)" in one and "Show new" (flush queued) in this branch. 2 new posts should never trigger a flush

I did some more testing, just observing the same timeline on this branch and on my instance without it, for some reason in this branch it triggers the timeline "flush" much more often for no good reason. on my twkn it went from "Show new (6)" on both tabs to "Show new (8)" in one and "Show new" (flush queued) in this branch. 2 new posts should never trigger a flush
shpuld commented 2020-07-03 12:34:11 +00:00
Member
Copy link

if I let it sit, every single fetch triggers the flush, something is wrong with the since_id since the request returns 20 posts but much less is actually added to the timeline, so it contains a bunch of duplicates

if I let it sit, every single fetch triggers the flush, something is wrong with the since_id since the request returns 20 posts but much less is actually added to the timeline, so it contains a bunch of duplicates
shpuld commented 2020-07-03 16:18:32 +00:00
Member
Copy link

after an hour or two of debugging or so, I found the bug lol

after an hour or two of debugging or so, I found the bug lol
shpuld commented 2020-07-03 16:20:28 +00:00
Member
Copy link

how reasonable would unit tests be for his function? it's pure at least

how reasonable would unit tests be for his function? it's pure at least
shpuld commented 2020-07-03 16:21:38 +00:00
Member
Copy link

marking this thread as resolved, bug found at #2170

marking this thread as resolved, bug found at https://git.pleroma.social/pleroma/pleroma-fe/pulls/2170?diff_id=14929#note_65960
eugenijm commented 2020-07-03 16:26:04 +00:00
Author
Member
Copy link

ah, nice catch! sure, will write a unit test soon

ah, nice catch! sure, will write a unit test soon
eugenijm commented 2020-07-03 17:08:15 +00:00
Author
Member
Copy link

added the unit tests

added the unit tests
shpuld commented 2020-07-03 17:37:29 +00:00
Member
Copy link

maybe we should have some sort of explanation why we put maxId into minNew

maybe we should have some sort of explanation why we put maxId into minNew
shpuld commented 2020-07-03 17:44:02 +00:00
Member
Copy link

fetchAndUpdate doesn't seem to take pagination object at all

fetchAndUpdate doesn't seem to take pagination object at all
shpuld commented 2020-07-03 18:12:29 +00:00
Member
Copy link

functionality wise now both bookmarking and timelines seem to work just right 👍

I'll still do a bit more side-by-side testing with this vs old to make sure things work the same

functionality wise now both bookmarking and timelines seem to work just right :thumbsup: I'll still do a bit more side-by-side testing with this vs old to make sure things work the same
shpuld commented 2020-07-03 19:00:09 +00:00
Member
Copy link

I think something as simple as

  // Mismatch between API pagination and our internal minId/maxId tracking systems:
  // pagination.maxId is the oldest of the returned statuses when fetching older,
  // and pagination.minId is the newest when fetching newer. The names come directly
  // from the arguments they're supposed to be passed as for the next fetch.

might do

I think something as simple as ``` // Mismatch between API pagination and our internal minId/maxId tracking systems: // pagination.maxId is the oldest of the returned statuses when fetching older, // and pagination.minId is the newest when fetching newer. The names come directly // from the arguments they're supposed to be passed as for the next fetch. ``` might do
eugenijm commented 2020-07-03 19:25:39 +00:00
Author
Member
Copy link

Thanks, sounds very good, added the explanation

Thanks, sounds very good, added the explanation

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
BE Request

   
Backlog

   
Better behavior

   
Blocked by deps

   
Bug

   
Code Review

   
Discussion

   
Doing

   
Feature Request / Enhancement

   
In the shining bright future maybe

   
It's complicated

   
MS Edge

   
Mememoon (or other niche browsers)

   
Missing API

   
Missing feature

   
Missing l10n/i18n

   
NL1
Instance Admin Dashboard

  
NL2
Improved Mobile Experience

  
NL4
Improved instance customization and QoL options

  
Need to verify on develop

   
RELEASE BLOCKER

   
Reassign or Close

   
Refactor

   
Regression

   
Safari

   
To Do

   
User story

   
Waiting on godot

   
accessibility
https://git.pleroma.social/pleroma/pleroma-fe/-/snippets/7746

  
better documentation

   
chore

   
confirmed

   
easy ticket

   
incident
Denotes a disruption to IT services and the associated issues require immediate attention

  
l10n update

   
mastoapi

   
mobile

   
needs design

   
needs-info

   
needs-review

   
stupid
No labels
BE Request
Backlog
Better behavior
Blocked by deps
Bug
Code Review
Discussion
Doing
Feature Request / Enhancement
In the shining bright future maybe
It's complicated
MS Edge
Mememoon (or other niche browsers)
Missing API
Missing feature
Missing l10n/i18n
NL1
NL2
NL4
Need to verify on develop
RELEASE BLOCKER
Reassign or Close
Refactor
Regression
Safari
To Do
User story
Waiting on godot
accessibility
better documentation
chore
confirmed
easy ticket
incident
l10n update
mastoapi
mobile
needs design
needs-info
needs-review
stupid
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
7 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
pleroma/pleroma-fe!2170
No description provided.