Pinned feeds cards

[estrattonbailey]

Replaces the lil avi+feed name at the top of the Feeds screen. Adds support for lists in FeedCard. Fixes alignment on mobile.

One small improvement from prod is that there's a pressed state on native now, that matches the hover on web.

[render]

Your Render PR Server URL is https://social-app-pr-4526.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cpmc0ol6l47c73btvia0.

[github-actions]

Old size	New size	Diff
6.31 MB	6.31 MB	2.23 KB (0.03%)

---

[gaearon]

this loading sequence feels a bit janky. some ideas:

1. use a glimmer for the top section too
2. maybe don't show the bottom section until the top one has loaded — it's just distracting that it'll jump soon

loading.mov

[gaearon]

let's polish the loading sequence a bit

[estrattonbailey]

Oh yep, meant to do this, I have a good idea for how to do this nicely I think

[estrattonbailey]

Added a skeleton loading state.

Cool thing we can do here is load the exact # of placeholders we need, bc we should have preferences loaded and therefore know how many saved feeds the user has.

RQ has a placeholderData param that we can use to provide initial data, and a isPlaceholderData state we can use in place of isLoading.

On warm loads i.e. navigation, we have prefs loaded so we can smoothly show placeholder -> real cards. On cold loads, prefs haven't loaded yet, so even the placeholderData will have a count === 0. In this case, we show 4 placeholders.

I double checked this in a no-feeds state, which can only happen if the user rugs their feeds in a 3p app or directly via API access, and the logic still works as it has been.

[estrattonbailey]

And pushed a fix for a flash of the load state when pinning. RQ let's us re-use the previous query result as the next placeholder state when the query is invalidated after a pin.

[gaearon]

jump.mov

The initial load is still jumpy because we're showing both sections despite not knowing the height of the first section. So once the first section arrives, it re-layouts. Two questions:

• Can we show My Feeds and the My Feeds glimmer alone (without Discover and Discover glimmer) until the query below has loaded? Similar to how we load the profile screen top-to-bottom (even if we have the bottom data earlier). This would avoid the layout jump.
• What is the reason for the second glimmer -> content transition? Meaning the transition from when I see a correctly-sized glimmer (presumably by this point we know the number of pinned feeds) to when I see all content. How come we know the number of My Feeds but not their content? Intuitively I'd expect us to know both from a single request.

To sum up, I'd expect this screen to load in two stages:

1. The first stage is My Feeds and a generic glimmer. No bottom section if the top section isn't ready.
2. The second stage is either all content being ready or My Feeds content being ready (with Discover still loading).

[estrattonbailey]

Yeah good idea. The goal of this PR isn't to totally redo this page, I just want to get rid of the n+1 queries we're doing for each saved feed and all the feeds under the bottom section (that bit I did last week).

I think I explained the multiple glitters above. On cold loads it's due to preferences not having been loaded yet. But I could see an argument for not jumping between the base of 4, to the actual # of feeds, to the loaded feeds. We could just show 4 or so and then wait for feeds data and show all feeds fully loaded.

Keep in mind that's only on cold loads though. With warm preferences data, I think it's super nice.

I'll look at the staged loading you're suggesting and see if it's easy to hit.

[gaearon]

Would be good to get this fixed:

regr.mov

Feels disorienting. Should doable by implementing placeholderData that looks at saved feeds + suggested feeds queries.