Fix mislabeled 'Recommended for you', hardcoded mainnet badge, dead error status, and inert Create bounty button - #320
Merged
Conversation
…nties" The section was labeled "Recommended for you" but available is simply bounties.filter((b) => b.status === "open"), sliced to the first 4 in whatever order the backend/mock data returns them — no relevance scoring against the signed-in contributor's history, languages, or past claims. "Recommended for you" implies a personalization that doesn't exist anywhere in this code path; this page doesn't even fetch the languages/organizations data (already available on ReputationProfile) that a real recommendation would need. Renamed to the honest "Open bounties" rather than building relevance scoring this page has no data plumbing for yet — matches the suggested fix's first option (closes MergeFi#239).
The hero badge hardcoded "Built for Stellar Mainnet" as a literal, entirely independent of STELLAR_NETWORK — the same value NetworkBadge.tsx already exists specifically to surface accurately, with its own doc comment explaining why showing the wrong network is dangerous. A deployment configured with NEXT_PUBLIC_STELLAR_NETWORK=TESTNET (exactly the case where NetworkBadge's navbar indicator *does* show, to warn visitors) rendered a homepage hero flatly contradicting that warning: "Built for Stellar Mainnet" directly above marketing copy about low transaction costs and fast settlement, while the navbar a few pixels above correctly flagged that this build isn't on the real network at all — a meaningfully misleading claim for a fundraising/escrow product, not just a copy nit. Now reads "Built for Stellar Mainnet" only when STELLAR_NETWORK === "PUBLIC", otherwise the honest "Built for Stellar (Testnet)" (closes MergeFi#238).
…reate bounty fetchBounties (lib/api.ts) already catches every failure internally and resolves to the fallback argument instead of rejecting — it can never throw, so the try/catch here that set statStatus = "error" on catch was unreachable dead code. statStatus was "loaded" in literally every case, including when the live fetch silently failed and fell back to mockBounties, so the maintainer dashboard had no way to distinguish live data from "backend down, showing 5 hardcoded mock bounties" — contrary to what the surrounding comment claimed. Detected the fallback case by reference instead: fetchBounties returns the exact fallback array on failure, but always a freshly-mapped array (a new reference) on a real live fetch, so this reliably distinguishes the two cases without changing fetchBounties' shared contract, which other pages depend on for its transparent-fallback behavior (closes MergeFi#240). Also, the "Create bounty" action rendered as a bare <span> with button-styled classes but no onClick or href — visually identical to a real call-to-action, but clicking it did nothing. The contributor and sponsor dashboards' equivalent action buttons are both wrapped in <Link href="/issues">; this was the only one of the three left unwired. Wrapped it the same way — bounties are created from GitHub issues per this page's own subtitle, so /issues is the natural destination (closes MergeFi#241).
|
@boluwacodes is attempting to deploy a commit to the chonilius' projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@boluwacodes Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Four fixes across the contributor dashboard, homepage hero, and maintainer dashboard:
Mislabeled "Recommended for you" (#239) — the section was labeled as personalized, but
availableis simply every open bounty sliced to the first 4, in whatever order the backend/mock data returns them — no relevance scoring against the contributor's history, languages, or past claims. This page doesn't even fetch thelanguages/organizationsdata (already available onReputationProfile) that real personalization would need. Renamed to the honest "Open bounties" rather than building relevance scoring this page has no data plumbing for yet.Hardcoded "Built for Stellar Mainnet" (#238) — the hero badge was a literal, entirely independent of
STELLAR_NETWORK, even though this app already hasNetworkBadge.tsxspecifically for surfacing that value accurately. A deployment configured withNEXT_PUBLIC_STELLAR_NETWORK=TESTNET(exactly the case whereNetworkBadge's navbar indicator does show, to warn visitors) rendered a hero flatly contradicting that warning — a meaningfully misleading claim for a fundraising/escrow product. Now reads "Built for Stellar Mainnet" only whenSTELLAR_NETWORK === "PUBLIC", otherwise "Built for Stellar (Testnet)".Dead error-status detection (#240) —
fetchBountiesalready catches every failure internally and resolves to itsfallbackargument instead of rejecting, so thetry/catcharound it that setstatStatus = "error"was unreachable dead code — the maintainer dashboard had no way to distinguish live data from "backend down, showing 5 hardcoded mock bounties." Detected the fallback case by reference instead:fetchBountiesreturns the exact fallback array on failure, but always a freshly-mapped array (a new reference) on a real live fetch — this reliably distinguishes the two without changingfetchBounties' shared contract, which other pages depend on.Inert "Create bounty" button (#241) — rendered as a bare
<span>with button-styled classes but noonClickorhref— visually identical to a real CTA, but did nothing when clicked. The contributor and sponsor dashboards' equivalent buttons are both wrapped in<Link href="/issues">; this was the only one of the three left unwired. Wrapped it the same way.Changes
src/app/dashboard/contributor/page.tsx— section renamed.src/app/page.tsx— hero badge now derived fromSTELLAR_NETWORK.src/app/dashboard/maintainer/page.tsx— fallback-detection fix +Create bountynow links to/issues.Test plan
npx tsc --noEmit— cleannpx eslinton all changed files — cleannpx jest(full suite) — 202/202 passing, no regressionsCloses #239
Closes #238
Closes #240
Closes #241