Architecture changes for DApp details view

[dandheedge]

Summary

Currently, the explorer rollups will need to support different cases, e.g. as a Web application maintained by us to consume all the DApps and provide a few pieces of information about each one of them, containerize to run locally to support the development and as a part of the deployment package for a single DApp when it is deployed somewhere. Hence, that differs from the usual web app; maintenance is gold here.

Engineering

We have a few stable structures in place.

1. The home page / where we provide an overall number of DApps and inputs and a paged list of DApps.
2. The DApp details page /dapp/address-of-the-dapp with more informational data when possible about the DApp.
3. A graphQL folder with queries and schema definitions and also a codegen.yml that we use to instruct code generation and save the artefacts on src/generated folder.

Outcome & references

We want two things out of this issue.

1. We want to update the graphQL queries definitions and codegen.yml so that we can have a generated folder with versions inside it. src/generated/v0.8 and src/generated/v0.9 or something close to that with clear package/namespace separation. The rollups from v0.6.x to v0.8.x will benefit from the same queries and type definitions. The v0.9 has breaking changes; the Epochconcept is gone from the graph tree, and now it is all about the Input.
2. Isolate the content displayed in the DApp detail screen using the Container pattern as discussed previously. It should use the rollups version of that DApp to decide which container to use.

I am adding the tasklist in a specific order because the expected code generation structure will be used to inject in the containers. So, generation first and UI second.

Tasklist code generation:

• [x] Add the typedef for v0.9 (in alpha) to our base code.
• [x] Update the config for code generation to generate separate outputs for graphQL queries and types based on the versions.
• [x] Should continue to work when commands like dev and build comes from Turborepo i.e. from the root folder.

Tasklist UI:

• [x] Containerize the current DApp details page that is for v0.6. In theory v0.8 DApps should work out of the box
• [x] Add the logic to decide which container to use based on the DApp factory version. Check the graphQL REF to see how you can retrieve info about it.
• [ ] Add tests for the container pattern new logic

ps: Keep an eye on GitHub-actions and Vercel CI.

GraphQL endpoint

Available query to retrieve data about the factory version: `dapps` | `dapp` | Network | Endpoint | | --- | --- | |  | https://api.thegraph.com/subgraphs/name/cartesi/rollups-goerli | |  | https://api.thegraph.com/subgraphs/name/cartesi/rollups-arbitrum-goerli |

[tuler]

We can remove support for 0.8

[brunomenezes]

We can remove support for 0.8

Ok, the schemas will be focused on v0.9, but for now, let's keep the graphQL-generated content in a versioned way (i.e. generated/graphql/0.9). Moving forward, we can "hit the nail" on this versioning decision.

@dandheedge, Is the change in the current development clear?

[dandheedge]

We can remove support for 0.8

Ok, the schemas will be focused on v0.9, but for now, let's keep the graphQL-generated content in a versioned way (i.e. generated/graphql/0.9). Moving forward, we can "hit the nail" on this versioning decision.

@dandheedge, Is the change in the current development clear?

Clear. Currently working on the generated folder structure and the revision on this PR https://github.com/cartesi/explorer/pull/8