-
Notifications
You must be signed in to change notification settings - Fork 15
Description
Background
- In PR 1071 an opportunity was documented in
apps/ensadmin/src/app/name/[name]/page.tsxfor creating a distinct data model for the subjective ENS Profile data model as used in ENSAdmin. - A related idea is implemented in the official ENS Manager app in their
useProfilehook: https://github.com/ensdomains/ens-app-v3/blob/5cf6e9d5459c4c9159315f371985a7d0138e12c4/src/hooks/useProfile.ts - Related issue: Dynamic resolution of all texts / addresses discovered via indexing #1083
Goals
Each app (including ENSAdmin) should define their own "wrapper" data model around their useRecords queries that is specific to their use case.
This data model should take the responsibility of hiding the nuances or complexities of a raw useRecords API response from the broader app. The broader app should be given a more simple and tailored data model to work with to make related code in the app as simple as possible.
- Design a nice data model for
ENSProfilein ENSAdmin that's completely optimized for ENS Profiles in ENSAdmin and doesn't worry about being useful outside of ENSAdmin contexts. - Create a
useProfilehook that internally callsuseRecordsand then performs the data transformations that might be required to return the nice, clean, and specializedENSProfiledata model. - Update the code in
ProfileHeader,ProfileInformation,SocialLinks,Addresses, andAdditionalRecordsso that their input changes to just taking anENSProfileas returned byuseProfile.- Remove logic in these UI components that are too specific to the nuances or complexities of a raw
useRecordsdata model.
- Remove logic in these UI components that are too specific to the nuances or complexities of a raw
Metadata
Metadata
Assignees
Labels
namehash-uiNameHash UI relatedNameHash UI related
Type
Projects
Status
On deck