fix(site): live GitHub star count on the landing page (client-side, no build-time fetch)#153
Merged
Merged
Conversation
The count was baked in at build time (getStars() in src/lib/github.ts) and only re-fetched when site/** changed and the Pages workflow ran, so the hero button drifted behind the real count (showed 26 while the repo was at 30). Keep the build-time value as the no-JS fallback and add a small bundled client script in Hero.astro that re-fetches stargazers_count from the GitHub API on load and updates the badge, reusing formatStars. Always render the .cnt span (hidden when empty) so the client can populate it even if the build-time fetch was rate-limited to null.
There was a problem hiding this comment.
Pull request overview
This PR adds progressive enhancement to keep the landing page GitHub star count up to date without requiring a new site deploy, while preserving the build-time value as a no-JS fallback.
Changes:
- Export
REPOfrom the GitHub stars helper so it can be reused in client code. - Always render the
.cntspan (hidden when empty) and add a small client-side fetch to refreshstargazers_counton page load.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| site/src/lib/github.ts | Exports REPO for reuse outside build-time fetching. |
| site/src/components/Hero.astro | Ensures the star count span is always present and refreshes the count via a client-side GitHub API fetch. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <a class="starbtn" href="https://github.com/onsails/right-agent"> | ||
| <svg class="ico" viewBox="0 0 24 24" width="15" height="15" fill="currentColor" aria-hidden="true"><path d="M12 2l2.9 6.9 7.1.6-5.4 4.7 1.6 7L12 18.3 5.8 21.2l1.6-7L2 9.5l7.1-.6z"/></svg> | ||
| star on github{starLabel && <span class="cnt">{starLabel}</span>} | ||
| star on github<span class="cnt" hidden={!starLabel}>{starLabel}</span> |
…t-side The build-time getStars() call was now redundant: the client already re-fetches the live count, so the CI build's GitHub API request only produced a value that goes stale between deploys (the original bug) and depends on the unauthenticated CI rate limit. Remove getStars()/the module cache and the await in Hero.astro and Landing.astro. Render neutral initial badges (nav 'star', hero empty hidden span) and consolidate refresh into a single fetch in the Landing layout that updates BOTH badges — the nav chip (.starchip) and the hero button (.starbtn .cnt). The nav chip was previously left stale; it is now covered too.
onsails
changed the title
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
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.
Problem
The landing page showed 26 GitHub stars while the repo was already at 30.
Not a code bug — the count was fetched at build time (
getStars()insite/src/lib/github.ts) and baked into the static HTML. The Pages deploy (.github/workflows/static.yml) only runs onsite/**changes or manual dispatch, so the number drifted behind reality between deploys. Two badges were affected: the hero button (.starbtn .cnt) and the nav chip (.starchip).Fix
Fetch the count client-side and drop the build-time API call entirely:
getStars()and the module cache;github.tsnow only exportsREPO+formatStars.star · N) and the hero button (N). ReusesformatStars; Astro tree-shakes the client bundle.star, hero empty hidden span), so there's nothing to go stale and no CI GitHub request / rate-limit dependency.Result: every visitor sees the current count, no rebuilds, no cron, no CI API call.
Trade-off
The count now appears a fraction of a second after load (client fetch), and visitors with JS disabled / third-party requests blocked see the button without a number. Acceptable for a decorative badge, and in exchange the number can never be stale again.
Verification
bun run build— succeeds; built HTML has neutral badges, exactly one inlined GitHub fetch that updates both selectors.bun run check(astro check) — 0 errors, 0 warnings.Merging this touches
site/**, which triggers the Pages deploy and ships the fix.