Fix "not found" messages before loading

[valiafetisov]

Goal

Not found messages in the UI no longer displayed on load.

Context

Currently,

• When a page to an auction is opened directly via url, the UI first show "This auction was not found" error and only later (a few seconds later) change it into the loading state
• When the main page is opened with the table or auctions, we also first display "No active auctions" and only a few moments later show loading state

Instead, the pages should always show loading state first or somehow indicate proper state of the auction
Please note that we once had a similar problem that was previously fixed: #90 (comment)

Assets

• Example url https://unified-auctions.makerdao.com/collateral?network=mainnet&auction=WBTC-A%3A26
• Example screenshot
  

Tasks

• Come up with several approaches to fix it, choose the best (we also don't want to show loading when it's not actually loading yet)
• Fix auction page error
• Fix auction table error

[aomafarag]

Since we always carry out a fetching attempt at least once when we open an auction, my approach would be:

• Combine the fetching props in a computed prop:

isFetching(): boolean {
  return this.areAuctionsFetching || this.areTakeEventsFetching;
}

• Add a new data prop to indicate whether an initial fetching attempt has taken place:

isFirstFetch: true;

• Add a new watcher for isFetching

isFetching(newIsFetching) {
  if (newIsFetching) {
    this.isFirstFetch = false;
  }
}

• Modify Loading component:

<Loading v-if="isFirstFetch || isFetching" />

• Add !isFirstFetch as an extra condition for the auction not found error

[valiafetisov]

Much more simpler approach would be to set areAuctionsFetching to true by default in the store, which would produce exactly the same result, right?

[aomafarag]

Much more simpler approach would be to set areAuctionsFetching to true by default in the store, which would produce exactly the same result, right?

Well, that was my very first approach, but I refrained from it due to this point in the issue description:

• Come up with several approaches to fix it, choose the best (we also don't want to show loading when it's not actually loading yet)

However, I don't think it would function the exact same way as it does not take areTakeEventsFetching into consideration. Setting both areAuctionsFetching and areTakeEventsFetching to true initially is a little sketchy imo.

[aomafarag]

I also have an improvement suggestion:

In store/network, we await each setup dispatch. My suggestion would be to run them all in parallel using Promise.allSettled(). This alone, btw, was a hacky pseudo-solution to the "not found" issue: the error message flashes for a few milliseconds (the user can't notice it).

[valiafetisov]

as it does not take areTakeEventsFetching into consideration

Those are two sequential events. Currently, in the container, we wait for the areAuctionsFetching to finish, then check if something was fetched and if not, fetch events. This was a temporary and quick workaround since it should all happen in the core and hopefully later be refactored. So I don't want to overcomplicate this logic now, since it's also does not add any benefits

I also have an improvement suggestion

This is out of scope of this issue, as far as I understand. Promise.allSettled() can create some undesired side-effects (eg 429 error codes). Instead, fetching of all auction types should be improved by checking the page we're currently in and only firing related actions (and re-firing them when page changes). You can work on this in another PR/issue.

[aomafarag]

Much more simpler approach would be to set areAuctionsFetching to true by default in the store, which would produce exactly the same result, right?

So, for now, I should go with this option for this issue, right?

[valiafetisov]

Yes, I think it would be ok. You just need to make sure (by reading the code and testing it for all types of auctions/vaults) that we always do those requests and clear up them to false (inside finally)