feat: expand entry read history

[hyoban]

Description

https://github.com/user-attachments/assets/1b612b35-c2ee-43d5-9fc5-09ac7b38b7d6

Linked Issues

Fixes #370 Fixes https://linear.app/follow-app/issue/FOL-126/follower过多无法展开

Additional context

https://github.com/RSSNext/follow-server/commit/7930d7370b4a408ec1f5f56c2e45cecca8872350

[linear[bot]]

FOL-126 follower过多无法展开

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
follow	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 14, 2024 6:13am

[Innei]

I feel like a dropdown menu would be more appropriate here, using a modal would make it feel very cut off.

[hyoban]

But the number of read history user IDs can be up to 100 now.

https://github.com/RSSNext/follow-server/commit/7930d7370b4a408ec1f5f56c2e45cecca8872350

Or do we revert it and keep it 20?

[Innei]

Just make it scrollable and infinite scrolling

[hyoban]

I do not know why. When I use drawer for UserProfileModal, it will open and quickly dismiss.

[Innei]

I will fix that

[Innei]

@hyoban

There is no problem with increasing the number of history records on the server side.

On the front end, it doesn't make sense to get to 100 records directly. Because in many cases users don't click More to see more users, the conversion rate is very low.

So to reduce the size of the data transfer and the pressure on the database itself. We should remove the entryReadHistories datafill from the entry interface on the server side, and then do the data paging in entries/read-histories/{id}.

In other words, there should be no read-histories queries or data in entries?id= right now. Instead, the API interface is separated into two.

[hyoban]

Got it, I'll take care of this part

[Innei]

I do not know why. When I use drawer for UserProfileModal, it will open and quickly dismiss.

@hyoban I fix this bug

[Innei]

@hyoban I'll merge it first, and then we can start a new branch to implement the above functionality.