-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DRY up popular feeds query #4501
Conversation
Your Render PR Server URL is https://social-app-pr-4501.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cpl39ntjm4es739c5ahg. |
!popularFeeds?.pages || | ||
popularFeeds?.pages[0]?.feeds?.length === 0 | ||
) { | ||
if (!popularFeeds?.pages) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First page can be empty, but subsequent pages will have results
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed code, tested on web and ios, looks good
data: InfiniteData<AppBskyUnspeccedGetPopularFeedGenerators.OutputSchema>, | ||
) => { | ||
const {savedFeeds, hasSession: hasSessionInner} = selectArgs | ||
data?.pages.map(page => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a mutation so it's not really selecting. Why is that?
The popular feeds query returns a static list of feeds. Some are not available logged out, and it returns feeds even if you've already pinned them. We had logic on the Feeds screen to filter based on session state and by which feeds you have saved.
I needed to reuse the same logic in #4491 and seemed like we could push this logic into the query handler itself.
This means that the popular feeds query will now return results with the feeds you've saved filtered out. We don't use this for anything else at the moment, and if we do need this, it'd be easy enough to add a param to this query to conditionally filter.
The only semi-noticeable change that this PR introduces is over-fetching if the first page of results doesn't return enough feeds that aren't already pinned. It reuses the exact pattern we used in
post-feed
to accomplish this. This will be used on the Explore page to show ~3 feeds on the first page of results, but that first page is likely to contain some feeds the user already has pinned, thus the need for over-fetching to ensure we get at least 3 (it may be more e.g. 5 if first page has 2 un-pinned feeds and second page has a full 3).