imo the biggest available improvement in this sort of case is using typescript

Chronik returns typed responses, so you can know exactly what is available when you have your response. Then you can make sure stuff renders according to what is available -- this means you can do things like render token icons immediately (only need a token id for this) -- then gradually render other features as the required data is loaded.

I'm assuming this means you can make synchronous API calls, let it process in the background, with cached data already loaded?

the API calls are async, but since each component owns its own API calls, they are all made in parallel, and each component loads as soon as it has the data it needs (vs before we were using promise.all, which did load all the data in parallel, but no orderbook could be rendered until we had the data for every orderbook).

The API call and all of the associated calcs are wrapped in try...catch

In the event of an error, we setAgoraQueryError(true) -- which renders a notice that there was an API query error. \

For now, if this happens, the only option for the user is to reload the page. We could handle it dynamically, but at the moment there isn't much point. If chronik call succeeds and the server is properly indexed, we will always get data of the expected shape (another example of why typescript here would give us some more confidence).

If the chronik call fails or the server is not properly indexed, there's really nothing we can do except inform the user we can't get the data.

There is never a need to make further API calls unless the user buys or cancels an offer, which we know will change the available offers in this orderbook. Going forward, it would be more robust and faster to use websockets to make changes to orderbooks based on market activity. Chronik already has the tech for this. But I think we should get it working with the API first.

websocket implementation would make agora as fast or faster than a CEX.

for this useEffect, we are saying "if we do not have the data we need to properly render the orderbook, then there is no point in calculating a validation error"

Because takeTokenSatoshis is constrained by the terms of each agora offer, the only validation we calculate is "will accepting this quantity result in an unspendable offer?"

No need to calculate this if we do not have the quantity data we need to show the user what he's buying.

We re-render whenever takeTokenSatoshis changes (depth bar fill changes, rendered prices and quantities change), but we do not make API calls unless the user buys or cancels an offer.

This is already gated by canRenderOrderbook, which requires activeOffers.length > 0

activeOffers is initialized as [] and can only be updated if we do not run into any errors in the try...catch that fetches and prepares the agora data.

So, we are already checking for these two conditions.

Another example tho of why typescript would help a lot.

This note is more for the dev than the user. titles can appear as tooltips, but in this case would only be briefly. But we can use titles (esp titles that appear at different loading stages) to confirm expected screen behavior.

tbh I had forgotten what the loading wallet context variable meant until digging into what specifically we had to do to avoid reloading the whole page on any user action. I think keeping the title more specific is more important than scaring the user, who probably never sees this (and, if he does, for long periods of time ... would be helpful to know as a dev).

more "we should use typescript"

similar to OrderBook, this is already gated.

activeOffersCashtab can only be null (if we are waiting on API calls) or an object with two arrays (if we avoid the try...catch errors in getListedTokens)

If it is null, then we are loading a spinner instead of this component

{activeOffersCashtab === null ? (
                        <Spinner title="Loading active offers" />
                    ) : (
                        <>
                            {loading && (

Possibly something is still going on and we get to a situation where Array.isArray(activeOffersCashtab.offeredFungibleTokenIdsThisWallet) is not true, and hence white screen of death. However if we are getting to this, need to understand why, and gate it.

I want to avoid adding unnecessary checks that may prevent whitescreen while concealing other unexpected behavior.

Again tho...the better answer here would be "use typescript"

same as above

if chronik API calls are successful, then we do not expect this to ever not be an array.

if chronik API calls fail, then this activeOffersCashtab === null and we do not render this component.