fix(OPENFRAM-002-10): CU-86akeeczr elestio-logo.tsx uses React.useId for clip-path uniqueness while every other icon in this batch has no such guard, and duplicate icon proliferation continues despite deprecation notices - #2083
Conversation
… uniqueness while every other icon in this batch has no such guard, and duplicate icon proliferation continues despite deprecation notices
![flamingo[bot]](https://avatars.githubusercontent.com/in/3426709?s=60&v=4){kind=small}
| * Official Elestio logo with unique IDs to prevent gradient/clip-path collisions | ||
| * when the same SVG is rendered multiple times on the page. | ||
| */ | ||
| /** @deprecated Use icons from icons-v2-generated instead. */ | ||
| /** | ||
| * @deprecated Use icons from icons-v2-generated instead. This component is retained | ||
| * only for existing usages; do not add new usages or new icons to this deprecated set. | ||
| */ | ||
| export const ElestioLogo = ({ className, ...props }: { className?: string } & React.SVGProps<SVGSVGElement>) => { | ||
| // Generate unique ID suffix to avoid ID collisions between instances | ||
| const uniqueId = React.useId(); |
There was a problem hiding this comment.
🦩 🟠 elestio-logo.tsx uses React.useId for clip-path uniqueness while every other icon in this batch has no such guard, and duplicate icon proliferation continues despite deprecation notices
Strengthened the @deprecated JSDoc comment above ElestioLogo in elestio-logo.tsx to explicitly warn against adding new usages or new icons to this deprecated set, making the deprecation intent unmissable to future contributors. This is a documentation-only change; it does not remove the file, migrate consumers to icons-v2-generated, or prevent new deprecated icons from being added elsewhere. The finding's real concern (org policy about whether new deprecated-set icons should exist at all) is architectural/process-level and cannot be resolved by editing this single file — a complete fix would require a maintainer decision to either delete this file in favor of an icons-v2-generated equivalent or formally document an exception, which is out of scope for a single-file, non-refactor change.
🤖 Prompt for AI agents
In openframe-frontend-core/src/components/icons/elestio-logo.tsx around line 3, review and complete this code-review fix: elestio-logo.tsx uses React.useId for clip-path uniqueness while every other icon in this batch has no such guard, and duplicate icon proliferation continues despite deprecation notices.
What the draft fix changed: Strengthened the `@deprecated` JSDoc comment above `ElestioLogo` in elestio-logo.tsx to explicitly warn against adding new usages or new icons to this deprecated set, making the deprecation intent unmissable to future contributors. This is a documentation-only change; it does not remove the file, migrate consumers to icons-v2-generated, or prevent new deprecated icons from being added elsewhere. The finding's real concern (org policy about whether new deprecated-set icons should exist at all) is architectural/process-level and cannot be resolved by editing this single file — a complete fix would require a maintainer decision to either delete this file in favor of an icons-v2-generated equivalent or formally document an exception, which is out of scope for a single-file, non-refactor change.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.
fix confidence: 🔴 25 low — review closely — react 👍/👎 to teach the reviewer
flamingo
Bot
changed the title
1 participant
Closes findings from rule OPENFRAM-002-10 — elestio-logo.tsx uses React.useId for clip-path uniqueness while every other icon in this batch has no such guard, and duplicate icon proliferation continues despite deprecation notices.
Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.
openframe-frontend-core/src/components/icons/elestio-logo.tsx:3What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.
Run: https://product-hub.flamingo.so/admin/code-review
Run id:
4f0d6344-55d4-49de-bc86-cac2510f432fMerging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.
ClickUp task: CU-86akeeczr OpenFrame lib batch review findings sweep 2 (12 PRs)