Mock data #269
Mock data #269
Conversation
draft jurors create votes create appeals
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/aragon/court-dashboard/49dp5yf44 |
There was a problem hiding this comment.
Haven't looked at the mocked information yet (i.e. anything in src/mock), but some thoughts:
- Could we pull the
src/mockfiles 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?
src/utils/juror-draft-utils.js
Outdated
| @@ -33,7 +33,7 @@ export function transformJurorDataAttributes(jurorDraft) { | |||
|
|
|||
| return { | |||
| ...jurorDraft, | |||
| weight: bigNum(weight), | |||
There was a problem hiding this comment.
Just sanity checking—are we sure in these cases where we're not using a BN anymore?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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).
Yep sure
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 |
Co-Authored-By: Brett Sun <[email protected]>
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:
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
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:mockI 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
High level implementation
At a high level, we use an environment variable
MOCK_DATAwhich when set will use our own fetch and subscription exchanges. These exchanges fetch data from themockfolder instead of the subgraph endpoint. The data to be resolved is determined by the queryoperationName.