feat(sparkling-history): router-agnostic navigation shim for MPA on Lynx [stack 1/6] - #8
Open
Huxpro wants to merge 1 commit into
Open
feat(sparkling-history): router-agnostic navigation shim for MPA on Lynx [stack 1/6]#8Huxpro wants to merge 1 commit into
Huxpro wants to merge 1 commit into
Conversation
A framework-agnostic W3C-History-style shim that lets URL routers drive Sparkling's multi-page native navigation, where each page is a separate Lynx container in its own JS heap connected only by a build-time route manifest. Layers (each a small, explicit contract): - NavigationHost: the platform floor — open/close stacked pages by URL. Ships a Sparkling binding (over sparkling-navigation) and an in-memory simulator. - SchemeCodec + RouteManifest: the cross-heap contract. A manifest generated from a file-based page convention is embedded in every bundle so isolated heaps agree on route -> scheme; route/state/depth ride across the boundary in the URL. - HybridRouterHistory: structurally compatible with a RouterHistory. In-heap it behaves like memory history; at the container boundary it delegates to the host (pushExternal opens a new container; go(-n) past the queue pops the native stack). - codegen: scans src/pages/* into a manifest module + an rsbuild/rspeedy plugin. No router framework dependency — any router that accepts a custom history can sit on top. 35 tests (memory-history suite ported from vue-router + cross-heap flows via the memory simulator). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ARyWgB3243gQx1exWK61Qb
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Jul 13, 2026
Open
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
Adds
sparkling-history, a framework-agnostic W3C-History-style shim that lets URL routers drive Sparkling's multi-page native navigation (MPA), where each page is a separate Lynx container in its own JS heap, connected only by a build-time route manifest. No router framework dependency — any router that accepts a custom history can sit on top.Related issues
Foundation shared by the router experiments (#1 TanStack, #2 Nuxt, #3 Vue Router). Standalone: contains no router-specific code.
Changes
sparkling-navigation) and an in-memory simulator.RouterHistory; in-heap it behaves like memory history, at the container boundary it delegates to the host.src/pages/*into a manifest module + an rsbuild/rspeedy plugin.How to test
Ported vue-router memory-history suite + cross-heap flows via the memory simulator.
Checklist
CONTRIBUTING.md.🤖 Generated with Claude Code
https://claude.ai/code/session_01ARyWgB3243gQx1exWK61Qb
Generated by Claude Code