feat: add dynamic metadata for search results

[maggienegm]

PR Checklist

• Addresses an existing open issue: fixes 🚀 Feature: Add SEO meta description tag for search results #67
• That issue was marked as status: accepting prs
• Steps in CONTRIBUTING.md were taken

Overview

This PR introduces dynamic metadata generation for the home/search page. It's metadata is now dynamically generated based on the searchParams in the URL:

{username} | Tidelift Me Up
{username} has {packageCount} npm packages eligible for Tidelift funding. 💸

This includes when a valid user has 0 packages eligible for funding based on search parameters. The metadata will look like the following:

{username} | Tidelift Me Up
{username} has 0 npm packages eligible for Tidelift funding. 💸

When no searchParams are provided, the default metadata is used, which is defined in layout.tsx:

Tidelift Me Up
Find your npm packages eligible for Tidelift funding. 💸

Also, something to note is that the API-related logic that was in page.tsx has been extracted into a separate file to improve code readability and maintainability.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
tidelift-me-up-site	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 15, 2025 9:30pm

[JoshuaKGoldberg]

Just noting for future reference, some test values:

• https://tidelift-me-up-site-git-fork-mag-dcddf3-josh-goldbergs-projects.vercel.app/?username=joshuakgoldberg&since=2024-11-06: as an example of 1 found package
• https://tidelift-me-up-site-git-fork-mag-dcddf3-josh-goldbergs-projects.vercel.app/?username=joshuakgoldberg: as an example of multiple found packages

[JoshuaKGoldberg]

🚀 This is looking great, thank you so much! Really excited to finally fix this darn accessibility/title bug.

Left a few comments and I think only about half of them are actually blockers. LMK what you think! 🙌

[maggienegm]

I just wanted to note that I've added caching to ensure data consistency between the generateMetadata and Home functions. Since these functions are run separately in the Next.js app lifecycle and cannot share data directly, they will still need to call fetchData separately, which includes the risk of data inconsistencies. Caching is one solution to address this.

I didn't see any existing caching in the app, so I chose node-cache. The node-cache package is a non-persistent in-memory caching solution. (Since this app doesn't have a traditional backend, it would store the data temporarily in the server's memory (RAM).) I believe this fits our use case since:
1) we don't need to have the data persist once a user closes the app,
2) and this will also ensure data consistency without having to make more fetch requests than needed.

[See comment below 😅]

With all that being said, would love to hear your thoughts!

[maggienegm]

Replaced node-cache with a built-in cache function.

[JoshuaKGoldberg]

This is great, thanks! The use of cache makes a lot of sense to me.