Mock data

[fabriziovigevani]

closes #225

This is an initial implementation to test the court without the burdens to setup everything locally or have a way to test different dispute phases as well as final rounds.

TODO:

• Add all posible account banner states for jurors
• Load evidences
• Add total jurors stat
• General Clean up code
• Add comments

This implementation attempts to keep a consistent data across the dashboard so some contract logic had to be implemented :D

Also updated some of the queries names to be more consistent with the data we are trying to fetch

Considerations

• Currently there are about 11 disputes created, each one of them with a different state or different result.

• There are 5 harcoded accounts that have participation in the court and these are the first 5 accounts from the default mnemonic that we use locally

myth like bonus scare over problem client lizard pioneer submit female collect

The first 3 accounts are jurors, the 4th is the appealer and the 5th the confirm appealer.

• Draft: For each round created we created drafts randomly between these 3 jurors, so on every page refresh you could see different results (jurors drafted for different disputes, dispute current ruling distribution changed, etc). What remains always unchanged are the dispute final results and previous round results (this will always be outcome: Blocked Action, appeal: Allow Action, Confirm appeal: Blocked action).

• Since we get some data from the contracts itself, this data is not available (e.g Subscription rewards, Total ANT staked, appeal deposits amount, etc)

• Actions are not possible here, it's read only for now.

How to test

You can run it locally by npm run start:local:mock

I recommend using Rinkeby or Mainnet since running locally requires to run Ganache and possibly also ipfs to see the disputes content (we are using the recent App mining dispute metadata for all disputes)

So you can do

npm run start:rinkeby:mock
#or
npm run start:mainnet:mock

High level implementation

At a high level, we use an environment variable MOCK_DATA which when set will use our own fetch and subscription exchanges. These exchanges fetch data from the mock folder instead of the subgraph endpoint. The data to be resolved is determined by the query operationName.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/aragon/court-dashboard/49dp5yf44
✅ Preview: https://court-dashboard-git-mock-data.aragon.now.sh

[sohkai]

Haven't looked at the mocked information yet (i.e. anything in src/mock), but some thoughts:

• Could we pull the src/mock files out into another PR that builds after this? There are a lot of uncontroversial changes here that are going to cause merge conflicts otherwise, and we should merge them in as soon as possible
• Do we require any network information when in the mocked state? Just the IPFS gateway and information from ETH nodes, but not the subgraph?

[sohkai]

Just sanity checking—are we sure in these cases where we're not using a BN anymore?

[fabriziovigevani]

For regulars rounds the juror weight will be at most 81 (and that is if a juror get's all available slots of a round ,highly unlikely). For final rounds it will be the number of times the juror has the min active balance which it's also unlikely to be too big for it to not be supported.

[sohkai]

So now I'm wondering... I think we did this in a few other places to make the code simpler, but maybe we should align all the internal numbers to be BNs?

Otherwise it might get confusing later—weight is a normal number, but round.number is a string and round.collectedTokens is a BN. The string / BN difference can make sense (some are identifiers, some are meant for calculations), but juggling two number representations can be frustrating unless they're clearly delinated (e.g. suffixing Bn in variable names or moving all the normal numbers to a separate field).

[fabriziovigevani]

Could we pull the src/mock files out into another PR that builds after this? There are a lot of uncontroversial changes here that are going to cause merge conflicts otherwise, and we should merge them in as soon as possible

Yep sure

Do we require any network information when in the mocked state? Just the IPFS gateway and information from ETH nodes, but not the subgraph?

We don't require the subgraph information because on the mocked env we use our custom subscription exchange which will fetch our own mocked data (in src/mock) querying by the operation name.