chore(namehash-ui): Copy shared components from ENSAdmin & ENSAwards #1507
Conversation
🦋 Changeset detectedLatest commit: cb8e5c1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
packages/namehash-ui/src/components/registrar-actions/RegistrarActionCard.tsx
Fixed
Show fixed
Hide fixed
…/feat/copy-components-to-namehashui
lightwalker-eth
left a comment
lightwalker-eth
left a comment
There was a problem hiding this comment.
@Y3drk Nice updates 👍 Reviewed and shared feedback. Please feel welcome to take the lead to merge when ready. Thanks!
| ``` | ||
|
|
||
| Note: `@ensnode/ensnode-react` is necessary only for some components. It might happen that you won't need it. | ||
| Note: `@ensnode/ensnode-react` is necessary only for some components. It might happen that you won't need it. Same goes for `sonner` it's only necessary for `CopyButton` component. |
There was a problem hiding this comment.
Why is sonner only necessary for the CopyButton component? I assume this is for tooltips? Don't all our apps use tooltips and therefore don't all our apps require sonner?
| "hooks": "@/hooks" | ||
| }, | ||
| "iconLibrary": "lucide" | ||
| } No newline at end of file |
There was a problem hiding this comment.
It looks like something is causing some files not to always include a newline character at the end automatically as part of our lint / auto-formatting steps?
| ``` | ||
|
|
||
| Note: `@ensnode/ensnode-react` is necessary only for some components. It might happen that you won't need it. | ||
| Note: `@ensnode/ensnode-react` is necessary only for some components. It might happen that you won't need it. Same goes for `sonner` it's only necessary for `CopyButton` component. |
There was a problem hiding this comment.
Would it be helpful here to identify how these packages are configured as peerDependencies?
| "boring-avatars": "^2.0.4", | ||
| "class-variance-authority": "^0.7.1", | ||
| "clsx": "^2.1.1", | ||
| "date-fns": "^4.1.0", |
There was a problem hiding this comment.
Do we not have date-fns as a "workspace:*" dependency as configured in pnpm-workspace.yaml?
| "@ensnode/ensnode-sdk": "workspace:*", | ||
| "@radix-ui/react-avatar": "^1.1.10", | ||
| "@radix-ui/react-slot": "^1.2.3", | ||
| "@radix-ui/react-tooltip": "^1.2.8", |
There was a problem hiding this comment.
Interesting, so we need sonner on top of these other tooltip libraries?
| * @returns complete block explorer URL for a specific address on a specific chainId, | ||
| * or null if the referenced chain doesn't have a known block explorer | ||
| */ | ||
| export const getBlockExplorerUrlForAddress = (chainId: ChainId, address: Address): URL | null => { |
There was a problem hiding this comment.
| export const getBlockExplorerUrlForAddress = (chainId: ChainId, address: Address): URL | null => { | |
| export const getBlockExplorerAddressDetailsUrl = (chainId: ChainId, address: Address): URL | null => { |
| * @returns default block explorer URL for the chain with the provided id, | ||
| * or null if the referenced chain doesn't have a known block explorer | ||
| */ | ||
| export const getChainBlockExplorerUrl = (chainId: ChainId): URL | null => { |
There was a problem hiding this comment.
| export const getChainBlockExplorerUrl = (chainId: ChainId): URL | null => { | |
| export const getBlockExplorerUrl = (chainId: ChainId): URL | null => { |
| } | ||
|
|
||
| /** | ||
| * Gets the base block explorer URL for a given chainId |
There was a problem hiding this comment.
| * Gets the base block explorer URL for a given chainId | |
| * Gets the "base" block explorer URL for a given ChainId |
| * @returns complete block explorer URL for a specific transaction hash on a specific chainId, | ||
| * or null if the referenced chain doesn't have a known block explorer | ||
| */ | ||
| export const getBlockExplorerUrlForTransactionHash = ( |
There was a problem hiding this comment.
| export const getBlockExplorerUrlForTransactionHash = ( | |
| export const getBlockExplorerTransactionDetailsUrl = ( |
| * @returns ENS Manager App URL for the provided namespace, or null if the provided namespace | ||
| * doesn't have a known ENS Manager App | ||
| */ | ||
| export function getEnsManagerAppUrl(namespaceId: ENSNamespaceId): URL | null { |
There was a problem hiding this comment.
| export function getEnsManagerAppUrl(namespaceId: ENSNamespaceId): URL | null { | |
| export function getEnsManagerUrl(namespaceId: ENSNamespaceId): URL | null { |
Substantial PR → Copy shared components from ENSAdmin & ENSAwards
Reviewer Focus (Read This First)
What reviewers should focus on
packages/namehash-ui/src/components/identity/ResolveAndDisplayIdentity.tsx:ResolveAndDisplayIdentityPropsandpackages/namehash-ui/src/components/registrar-actions/RegistrarActionCard.tsx. I suggest reasoning about the changes made, focusing on differences in how each of our apps displaysregistrar-actionsProblem & Motivation
Why this exists
Phase 3&Phase 4of the strategy suggested in the aforementioned Issue.What Changed (Concrete)
What actually changed
package.jsonandREADME.mdfiles accordingly.Design & Planning
How this approach was chosen
Phase 3&Phase 4Self-Review
What you caught yourself
packages/namehash-ui/src/components/identity/ResolveAndDisplayIdentity.tsx:ResolveAndDisplayIdentityPropsmight seem weird (the addition ofidentityLinkDetails), but with how our registrar actions display is designed across our apps, I found it the best way to keep the code usable across both of them without any design changes. Feel free to attack it.Cross-Codebase Alignment
ensawards,ensadmin, anddocs/ensrainbow.io.❌ move cancelled🔁 postponedDownstream & Consumer Impact
Who this affects and how
namehash-uiitself, this PR shouldn't affect any of our apps, docs, or packages.namehash-ui/README.meTesting Evidence
in actionas I apply the package in our apps in later PRs, as they seem finein codewhen I review them now.namehash-uipackage. I expect that nothing bad should happen, but even if it does, it won't affect any of our apps, as none of them use the package yet.Scope Reductions
🔁 postponedRisk Analysis
How this could go wrong
namehash-uipackagenamehash-uipackagePre-Review Checklist (Blocking)