Two divergent ImageWithFallback components exist; the figma one is completely dead in production

[Jagadeeshftw]

Description

There are two separate, meaningfully different ImageWithFallback implementations in this repo:

1. src/app/components/figma/ImageWithFallback.tsx — retries the image load once by appending a ?retry=1 query param, then falls back to a base64-encoded broken-image SVG icon. No URL validation.
2. src/features/landing/components/ImageWithFallback.tsx — validates src is an http:/https: URL up front (isValidImageUrl), has no retry logic, and falls back to an animated bg-white/10 animate-pulse skeleton block instead of an icon.

A repo-wide search shows the first component (src/app/components/figma/ImageWithFallback.tsx) is never imported by any production code — its only reference anywhere in src/ is its own test file (src/app/components/figma/ImageWithFallback.test.tsx):

$ grep -rln "ImageWithFallback" src --include="*.ts*"
src/app/components/figma/ImageWithFallback.tsx
src/app/components/figma/ImageWithFallback.test.tsx
src/features/landing/components/ImageWithFallback.test.tsx
src/features/landing/pages/LandingPage.test.tsx
src/features/landing/pages/LandingPage.tsx
src/features/landing/components/ImageWithFallback.tsx

Only LandingPage.tsx imports an ImageWithFallback, and it imports the features/landing one. The figma version is fully-formed, exported, documented, and tested — but unreachable from any route, meaning it represents dead production code (and dead test coverage) that anyone searching for "the" ImageWithFallback component would reasonably (and incorrectly) assume is in use, given how central image-fallback handling is across project logos, avatars, and blog art.

Requirements

• Decide on a single canonical ImageWithFallback implementation (the features/landing one is the actively-used one, and it's also the more defensive of the two since it validates the URL scheme before rendering).
• Delete src/app/components/figma/ImageWithFallback.tsx and its test, or — if the retry-on-error behavior is considered valuable — merge it into the surviving implementation and move it to a shared location (e.g. src/shared/components/) so both current and future consumers get one behavior.
• No behavior change to LandingPage.tsx's rendering.

Suggested execution

1. Fork the repo and create a branch: git checkout -b fix/remove-dead-imagewithfallback
2. Confirm (via grep -rln "ImageWithFallback" src) that src/app/components/figma/ImageWithFallback.tsx has zero production importers.
3. Delete src/app/components/figma/ImageWithFallback.tsx and src/app/components/figma/ImageWithFallback.test.tsx.
4. If the src/app/components/figma directory becomes empty, remove it.
5. Confirm the build, lint, and test suite are unaffected.

Example commit message

chore: remove dead figma ImageWithFallback duplicate

Acceptance criteria

• Only one ImageWithFallback component remains in the codebase.
• No production import is broken.
• The removed file's test is deleted alongside it (or migrated if behavior is merged).

Security notes

The retained (features/landing) implementation is the more secure of the two since it validates the URL protocol before rendering, rejecting non-http(s) schemes; standardizing on it removes the risk of a future consumer accidentally picking the less-defensive figma copy.

Guidelines

• Minimum 95% test coverage
• Timeframe: 96 hours

[1nonlypiece]

Hi Maintainers 👋,

I’d like to apply for this issue.

I have hands-on experience with Next.js frontend development as well as Stellar smart contracts using Rust (Soroban). I’m comfortable working with Figma designs, integrating APIs/wallets on the frontend, and implementing, testing, and optimizing smart contracts on Stellar.

I can follow the project guidelines, communicate progress clearly, and deliver clean, well-tested code within the expected timeline.

Looking forward to contributing to the project 🚀
Thanks!

[Jagadeeshftw]

Assigned @1nonlypiece! Go ahead and open a PR referencing this issue (Closes #881) when ready. t.me/+vTbe0hOUKrFhNTJl