feat: redirect browser fallback to farcaster.xyz/~/snap-preview

[bob-obringer]

Summary

• Replace inline HTML rendering with a redirect to farcaster.xyz/~/snap-preview?url={snapUrl} where the snap renders with real React components via SnapView
• Redirect page still serves OG meta tags for social media crawlers (they don't follow meta refresh)
• renderSnapPage.ts kept as fallback for options.fallbackHtml override

Depends on: merkle-team/monorepo snap-preview-page branch

Test plan

• curl -sS snap-url → HTML with OG meta + redirect URL
• curl -sS -H 'Accept: application/vnd.farcaster.snap+json' snap-url → snap JSON (unchanged)
• Browser visit → redirects to farcaster.xyz, snap renders

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
snap-docs	Ready	Preview, Comment	Apr 7, 2026 4:34pm

[CryptoExplor]

This is a meaningful UX improvement — the inline HTML fallback was a static dead end for users who opened a snap URL in a browser, while the redirect to farcaster.xyz/~/snap-preview gives them an actual interactive experience via SnapView. A few notes:

On the OG meta tags serving for crawlers: Smart approach — keeping the OG tags in the initial HTML response while using a <meta http-equiv="refresh"> redirect means social previews (Twitter/X cards, Discord unfurls) continue to work since crawlers don't follow meta refreshes. Worth confirming the og:image and og:title in the fallback HTML are still populated from the snap's first-render response or a static manifest.

On renderSnapPage.ts kept as fallback for options.fallbackHtml: Good call preserving this escape hatch. Apps that self-host their own preview renderer (e.g., custom OG image generation) shouldn't be forced onto the redirect path. The opt-out via fallbackHtml is the right interface.

Dependency note: The PR says it depends on merkle-team/monorepo snap-preview-page branch. What's the plan if that branch ships first? Should this PR remain a draft until the monorepo side is merged, or is there a feature flag / graceful degradation if farcaster.xyz/~/snap-preview doesn't exist yet?

On the redirect URL construction: Should {snapUrl} be URL-encoded when appended as a query param? If the snap URL itself contains query params, the constructed redirect URL could break without proper encoding.

Looks good overall. Once the monorepo dependency is resolved, this should be ready to merge.