Fix: The Docs 404 Battle
A post-mortem on why URL parsing failed and how ID-First Addressing provided the solution.
🚑 Chronicle: The Docs 404 Battle & Recovery Roadmap
Status: Resolved via ID-Centric Discovery (Feb 2025)
Target: routes/$lang.docs.[...slug].tsx
1. The Post-Mortem: Why 100 Fixes Failed
We were trying to "Parse the String."
We assumed that if the URL was /zh/docs/core/plan, the router must give us the array ['core', 'plan'].
The Sandbox Reality: The router often returned undefined or a mangled string because of the blob: proxy. No amount of regex could fix a missing string.
2. The "Aha!" Moment: ID-First Addressing
We realized that the Slug is not the Data. The Slug is just a property of the data.
The Winning Strategy:
- Abandoned: Trying to make the Splat parameter (
*) work perfectly across all proxies. - Implemented: Treating the entire browser location as a "Search Query."
- The Protocol:
- The Loader grabs whatever string is available in the URL.
- It treats that string as a Candidate ID.
- It scans the
docs.sqliteregistry for any record that owns that string as a path or slug. - It fetches the content by the found Unique ID.
3. Conclusion
The 100-repair cycle ended the moment we stopped trusting the URL and started trusting the Database Registry.
New Rule: The Component doesn't know where it lives; it only knows what ID it's rendering.
Archived: This insight turned a fragile routing system into a bulletproof resource discovery engine.