Without virtualisation

[tb38r]

Withheld working on the virtualisation element to get a viable working product out.
Throttled getListSize to prevent server overload.
Updated with css changes from #264.
List count appears to the right of of the list name.
resolves #255.

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
clearsky-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 26, 2025 8:32pm

[thieflord06]

Passes functionality checks.

[tb38r]

Don't think the throttling is working as desired...
The count represents the count of the first list item (returns a 100 items at a time).
Hence why you get the same count for a bunch of items till you scroll with a new batch of items (all using the first's count)
Moving the throttling directly to the queryFn prop returns seemingly accurate data

but with this the 429 errors returns...
needs further investigation

[thieflord06]

Ah. I was wondering if this was just a fluke or because of list member limits.

[thieflord06]

What are the response times from the endpoint looking like? We may need to do some query optimizations.

[tb38r]

response time via postman

with about a 100ms variance

~181ms via the network tab on dev tools

Thinking about the problem, throttling client side wouldn't work as we're iterating through the AccountListEntry array and calling the hook at a rate of knots independently from each other. Perhaps some b/e rate limiting or something else entirely

[thieflord06]

I'll defer to your expertise or if you want to discuss in the discord that may help.

[thieflord06]

I'm circling back to this, I'm debating whether raising the limit is the correct solution. I'm ok with the list counts populating after the core list information. IDK if that's good UI/UX design.

Functionally, we may have no choice being the return of the 100 lists is instant.

@tb38r

[tb38r]

@thieflord06 , one possible solution would be for the count to be resolved server side. Assuming minimal overhead, could the count for each list be added within a new column in the db (alongside createdDate, name, url etc) ?

It could make up part of the AccountListEntry that's currently being returned and consequently fix this issue. Is this feasible?

[thieflord06]

We weren't doing that for lists but we were for blocks and we had to separate that out because it was slowing things down significantly.

[tb38r]

Gotcha, I'll give it some thought & see if I can land on an another solution

[noahm]

After taking a closer look at this I think I finally understand what is going on. First of all: client side throttling can definitely work here. Second: the lodash throttle utility is not a solution to this particular kind of rate limiting where different invocations are being called with different arguments. What we need in this scenario is a request queue where each one waits in order for its turn. I'll swap out the lodash util for an appropriate one and we can take it from there.

[noahm]

I believe this is now all working as intended. Review for functionality once more?

[thieflord06]

Looking good! Needs number formatting.

[noahm]

Oh, one last question here for @thieflord06: what is the actual underlying ratelimit enforced by the backend for the list totals (or against the entire api?) the once-per 500ms set on these lists is a bit slower than I would hope for.

[thieflord06]

5/sec for all anon endpoints.

[thieflord06]

Looks like, for my lists, they all loaded except for the last one.

It also looks like it's trying to retry but not showing.

It finally loaded, but it took a few times?

[thieflord06]

Once everything loads, it looks like if you leave the tab and go back to it, it tries to re-fetch everything.

Recording.2025-01-24.215251.mp4

[noahm]

I may be able to fix the re-fetching, but will either need to wait for sindresorhus/p-queue#220 to merge or I may end up publishing the fork myself

[thieflord06]

Do you think they'll review it in a timely manner?

[noahm]

It's fairly likely, but i'll probably just publish my form tomorrow afternoon if there's no activity by then

[noahm]

Alright, I've pulled in my forked package and tuned things up a bit. There was still a bit of a weird issue where the first couple of lists in a page can have their initial requests cancelled and then they get re-queued at the end of the list, so items 4-100 have to load their totals before the totals load in for lists 1-3. I solved that by using our existing "poor man's virtualization" technique that's already in use on block/blockedby tabs and reusing it on lists as well. Now the initial render should only include 20 items.

[thieflord06]

We'll take it. Looks good.