NoSignups (FckSignups)
Run NoSignups locally and add a fixture that matches the current schema
Use the documented Vite workflow, inspect the real Tool type and test category, search and editorial grouping with one harmless catalogue entry.
What you will learn
- Confirm the fetched dataset rather than trusting a populated screen.
- Current entries use section and an explicit tags array.
- Test both category filtering and all-keyword search.
Before you start
- Basic JavaScript and JSON knowledge
- A harmless sample task and catalogue fixture
Explain the chapter boundary and verify it using the proposed fixture or review record.
Key takeaways
- Confirm the fetched dataset rather than trusting a populated screen.
- Current entries use section and an explicit tags array.
- Test both category filtering and all-keyword search.
Establish which dataset you are looking at
The README’s setup is a repository clone followed by npm install and npm run dev. package.json maps dev to Vite, build to tsc followed by vite build, and preview to vite preview. Inspect the repository and dependency installation scripts before running them. This chapter provides the workflow; it does not claim that the entire upstream application has been installed or launched during editorial review.
In development, useTools first tries DEV_JSON_URL, defined as ../../../tools.json. If that request fails it tries the remote production JSON, and then the embedded fallback dataset. Consequently, seeing cards after a local edit is not enough to establish that your modified file loaded. Check the browser’s requested URL and response, then confirm a unique fixture name is actually visible.
Prefer the current type definition over a stale table
At the inspected revision, Tool requires tags as an array and uses section values featured, editors-pick or meets-criteria. The README describes tags as optional and documents a featured boolean instead. A fixture copied literally from that older table can therefore fail expectations in the current frontend. The source also distinguishes category IDs from their display names; use an ID present in the dataset you loaded.
Add a record with a unique id, a short name and description, a valid test URL, an existing category and explicit tags. The example uses example.com as a harmless placeholder, not as an actual utility. Put the record inside the tools array of a test copy of tools.json. Do not submit the fixture to the public project or replace a real entry to make the example fit.
Test the path from query to card
Choose a fixture whose name and tags make its expected matches obvious. Search for two known terms, then apply a different category and confirm the card disappears. Search is an all-keywords match over name, description and tags, not over the destination URL or repository URL. A phrase can match across different fields; it is not necessarily a contiguous phrase search.
Finally test an empty query, a query with no match and a non-Latin query. The inspected tokenizer keeps only lowercase ASCII letters, digits and plus signs, so a Chinese-only query becomes empty. That is a current behavior to understand and test, not a promise of multilingual search. Record these observations before describing the local installation as ready for a multilingual audience.
Implementation steps
- 1
Review and clone the repository into an isolated working directory.
- 2
Install dependencies, start the dev script and inspect the JSON request.
- 3
Add the fixture to a test dataset using a real category ID.
- 4
Check known matches, no matches and non-Latin input.
Copy-ready example
{
"id": "fixture-json-formatter",
"name": "Fixture JSON Formatter",
"description": "A harmless catalogue fixture, not a real hosted utility.",
"url": "https://example.com/",
"category": "development",
"tags": ["json", "formatter", "fixture"],
"section": "meets-criteria"
}Frequently asked questions
Why did my edited entry not appear?
Check the requested JSON URL and whether the loader fell back to GitHub or the embedded dataset. Also verify the selected category and search terms.
Can I omit tags as the README suggests?
The inspected Tool type requires tags, and matching spreads tool.tags. Use an explicit array and validate incoming records rather than relying on that README row.
Sources
- README.mdSource checked 2026-09-07
- package.jsonSource checked 2026-09-07
- vite.config.mtsSource checked 2026-09-07
- src/hooks/useTools.tsSource checked 2026-09-07
- src/components/Home/Tools/Tools.tsxSource checked 2026-09-07
- src/components/Home/Tools/ToolCard/ToolCard.tsxSource checked 2026-09-07
- src/types/index.tsSource checked 2026-09-07
- src/constants/fallbackData.tsSource checked 2026-09-07
- src/data/schema.jsSource checked 2026-09-07
- cloudflare-worker/worker.tsSource checked 2026-09-07
- cloudflare-worker/urlHandlers/handleSubmitTool.tsSource checked 2026-09-07
- cloudflare-worker/utils.tsSource checked 2026-09-07