feat: implement queries throttle for switch account component

[alter-eggo]

Try out Leather build 6c5eb45 — Extension build, Test report, Storybook, Chromatic

This pr throttles all balances queries on switch account list component, to prevent 429 errors

[kyranjamie]

I think adding the debounce directly to the hooks breaks the SRP, and generally makes them more complicated than they should be. Perhaps there might be better ways to handle adding a delay before requesting directly in the hook?

The main scenario I think about is the switch accounts lists. If a user scrolls down 300 accounts, we shouldn't queue up 300x balance and 300x bns name requests.

I reckon there are two mechanisms we could alternatively use to ensure that requests that aren't needed, don't get triggered

1. Client side rate limiting
   We use https://github.com/jhurliman/node-rate-limiter to ensure that we don't fire too many requests at once. These could be configured to trigger substantially less than the actual RPM, just to ensure we don't use too much. If a request is triggered and added to the queue then the component dismounts before the request is made, we use the AbortController to cancel the promise (and could even add back one unspent request to the rate limtier)
2. Component tree debounce.
   Another way to delay the request could be internal to the account item component. We could write code where we only render the component that has the query hook, 1second after render. This way, the request is never made until the component mounts. This is the same principal as what you've built here, but implemented in a way where we don't change the query hook implementatoin.

[kyranjamie]

If I have a request queued by the rate limiter, and the component dismounts, what happens?

[markmhendrickson]

@314159265359879 want to QA this one by trying to "break" it with wallets that have lots of accounts and assets?

[314159265359879]

tested this version

I see a lot of these errors (coingecko api) as I scroll through accounts to select the right one (testing with 400 accounts wallet):
is it checking the USD price per account? use old value unless more than 5 minutes old instead?

As soon as I open "select account" screen I get these 429's from hiro api's

looks like some bnsx calls and ordinals inscription calls.

Another odd thing, I am not sure if it is related to this PR when I switch from an account with a name to an account without a name the name remains displayed instead of "Account x"

I see a lot less 429's as I scroll over the accounts. I am still waiting for names to load though and there is no indication the wallet is doing anything. I feel like some of the API budget should be reserved so that BNS names and balances can be checked once the user stops scrolling for a few seconds. Or a way to force where to update next.

Scenario
I feel like I am close to the account I need (Account 160) but it could also be 161 or 162... once the name is loaded I would know.
Clicking the account... nothing happens because it is still waiting before making additional calls. Displaying the wrong name. I feel like it should have api budget to check that name right away or display the (correct) account number instead.

Could the wallet check for BNS names for all accounts (in the background even before account selection is started) and just save them to persist? And only update those when the user asks/click refresh-name? Names are not expected to change that often but they are rather vital for identifying accounts.
If loading the balances prevents it from loading data when an account is selected/entered into I don't think we're helping the user yet.
What about not loading any balances automatically on the account selection screen unless the user asks for it, a "load now" button" next to each account or a global one that starts loading balances from the top of what is visible when it is clicked?

Perhaps some of that is out of scope for this PR.
Leaving some API budget to check BNS name when account selected seems vital though.
I wonder if loading should pause for a bit longer before starting so the user has a chance to move to where they want the loading to start. I am not sure if the wait time could be made dependent on how many accounts are revealed in the wallet. I am sure you can start loading right away when there are only 5 accounts. When there are a hundred, let them roughly target first?

[314159265359879]

it looks like the coingecko API issue (error 403) was related to IP restrictions, please ignore. I don't see it now that I switched to another IP.

[alter-eggo]

@314159265359879 wonder if you could test latest build please

[314159265359879]

I have waited until it does something again but it is not loading the name yet after selecting. I think it is prioritizing loading bitcoin data perhaps... there is no bitcoin in any of these accounts so it is a bit odd.

When I switch account scroll down from 156 to 400... I see one name loading. The rest of these accounts have names too but they are not yet displayed.

is it possible to prioritize loading the names?

[fbwoolf]

At some pt we should add an alias for theme folder.

[fbwoolf]

@alter-eggo I downloaded the latest build here ...none of my Stacks NFTs are loading. 🤔

[alter-eggo]

@fbwoolf thanks for testing! fixed

[kyranjamie]

Great stuff @alter-eggo, just tried this out and works very well. Maybe we'll need to fine-tune some of the priority settings later, but this should already be such a huge improvement. Look forward to checking 429 errors pre/post these changes.

[markmhendrickson]

Does this apply to "Select account" for the recipient field of the send form as well?

[alter-eggo]

@markmhendrickson yes