Open Rashmi-278 opened 1 year ago
The better solution is not to hide it exactly but to allow to show up somewhere in the interface, so you can see the old one if you want.
Can group new+old registrations by unique tuple (name, contract address, network).
An alternate solution, this can be easily solved by adding a timestamp filed to the registration instance and having a filter which If the DAO Name is the same, displays the latest registration instance based on the timestamp
However, as the DAO Name isn't a unique identifier, one could register a new instance with the same DAO Name
Can group new+old registrations by the unique tuple (name, contact address, network).
This solution fails when the contract address is updated.
For now, When someone edits a registration Instance, they could submit this form https://forms.gle/GieH87a7LGrFRUnd6 for us to hide it. or They could create a PR for a change in this file to include their registration ID
As this scenario is rare, this would serve as a fallback solution.
Editing the registration and making the registrationSummoner contract call saves a new registration but the old one is still being displayed. As some of the edit fields deal with smart contract data, they cannot really be edited and it makes sense to consider it as a new registration, but we need to have a way to hide the old registrations to prevent duplicates on Explorer page.
One way to solve this would be to fetch the registrationId which is unique per registration and not per DAO, and add it to hide addresses on the frontend.
we would need to think of a design that is more equipped to handle things at scale when there would be more registrations and edits as a simple list filter of registrationId's would slow down the page load and cause bad UX.