Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-think part of the app's routing architecture in terms of remix routing? #51

Open
PJColombo opened this issue Jul 5, 2022 · 0 comments

Comments

@PJColombo
Copy link
Member

PJColombo commented Jul 5, 2022

It would be better to refactor the contract descriptor screen, separating some of their views components to their own route, following remix routing idea and harnessing the nested routes concept where multiple routes match portions of an URL to render specific components forming a hierarchy.

A possible routing design:

  • /contracts?q=<contract-address>: It renders the ContractSelectorScreen
  • /contracts/<network-name-abbr>:<contract-address>/functions/<sig-hash>/describe: It renders the ContractDescriptorScreen.
  • /contracts/<network-name-abbr>:<contract-address>/functions/<sig-hash>/test: It renders the TestModal

In regards of network-name-abbr, we would use abbreviations similar to Gnosis Safe's, e.g., gno, matic, eth, etc

@PJColombo PJColombo changed the title Re-think part of the app's routing architecture in terms of remix routing? Refactor part of the app's routing architecture in terms of remix routing? Jul 5, 2022
@PJColombo PJColombo changed the title Refactor part of the app's routing architecture in terms of remix routing? Re-think part of the app's routing architecture in terms of remix routing? Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant