Architecture changes for DApp details view #7
Labels
rollups
Changes targeted for Rollups Explorer
type:feature
new feature or improvement over an existing feature
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.
/
where we provide an overall number of DApps and inputs and a paged list of DApps./dapp/address-of-the-dapp
with more informational data when possible about the DApp.src/generated
folder.Outcome & references
We want two things out of this issue.
src/generated/v0.8
andsrc/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; theEpoch
concept is gone from the graph tree, and now it is all about the Input.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:
dev
andbuild
comes from Turborepo i.e. from the root folder.Tasklist UI:
ps: Keep an eye on GitHub-actions and Vercel CI.
GraphQL endpoint
Available query to retrieve data about the factory version:
dapps
|dapp
The text was updated successfully, but these errors were encountered: