Paginate rewards list

[gordsport]

Is dependent on https://github.com/vegaprotocol/vega/issues/6650

We need to refine this ticket based on the outcome of the API work.

Chore

Apply infinite scroll pagination to rewards list. Get me last 25 and use the cursor position to load the next 25 (basically you scroll the page and more epochs load in as you scroll.)

Background

This is holding up the work on removing the deprecated APIs.

Place holder issue:

• https://github.com/vegaprotocol/token-frontend/issues/780

[dexturr]

Realted to #802

[pennyandrews]

Might need some additional design for the edge cases i.e. handling loads of pages etc. @joellecharlotte

[pennyandrews]

For speed we made a call on the standup today to not make round buttons for the pagination but instead use the square with rounded corners that we have already in the UI toolkit. Sorry @joellecharlotte

[notbot00]

blocked by:

• https://github.com/vegaprotocol/vega/issues/7871 (https://github.com/vegaprotocol/vega/pull/7872)

[pennyandrews]

#7872 is part of core version 70.1 which is now deployed to stagnet1 and testnet so this ticket should be unblocked now

[notbot00]

I'm trying to understand what we're trying to do here exactly, but i have a feeling this is not possible to do with the current state of things.

Here's why.

In both of "total" and "earned by me" reward tabs we query for three things: epoch, available asset types, and the earned rewards. As a result, the frontend received three lists (epochs, assets and rewards). To be able to represent the rewards as we do now (categorised under a certain epoch, and summed up per asset), we do a lot of the heavy lifting on the frontend in terms of parsing all the data we get back from core, and index rewards by epoch, and sum items per asset type. We'd be able to request paginated data for the rewards list, but there'd be no guarantee for what that data would look like. For example, we could request for the last 15 rewards, which all are under the same epoch, and they are the same asset, which would result in displaying one epoch table with one row of assets. Imagine the second page we'd request would have 15 rewards all belonging to different epochs. There's no consistent way of displaying the categorised and summed up rewards data we display, because this type of data doesn't exist as such on core.

In order to be able to move forward with this, we could:

1. task core to create a new data type we could query for with pagination - either something like an assetReward type with the summed rewards for each assets per epoch (this would require the frontend to query epochs before, and send off a)
2. implement new designs, which are representing the data we can actually paginate, which are rewards in one table (not per epoch, and not summed up per asset), with displaying which epoch they belong to and what asset they are representing as e.g. columns
3. leave it as it is, and set a hard limit of how much data we're displaying on the rewards page so we don't break things

[barnabee]

4. Governance site team a database/service that takes the raw data node data and serves up the thing you want.

Not every front end page is going to have a perfect data node API. Maybe in this case it can/should be done (I am not sure…), but there is definitely another option that can and should be considered.