Sparkling
  • English

      • Vue Router (MPA)

      This example runs Vue Router on top of Sparkling navigation, so a single router configuration drives navigation across multiple native Lynx pages — the multi-page (MPA) model.

      It is built on sparkling-history, a framework-agnostic shim that implements Vue Router's history contract on top of Sparkling's router.open / router.close.

      Different from VueLynx's in-view router

      VueLynx supports Vue Router with createMemoryHistory to build an SPA inside a single LynxView (one JS heap). This example is the opposite: each page is a separate Lynx container in its own JS heap, and Vue Router drives native navigation between them. The heaps share no memory — only a build-time route manifest connects them.

      In-heap navigation (live in the web preview)

      The main bundle owns two routes, / and /features. Navigating between them is an ordinary Vue Router transition inside one heap — no native bridge is involved — so it runs live in the web preview below. Tap Features (or the in-container button) and watch the route change without opening a new page.

      vue-router-mpasrc/pages/main/views/Home.vue
      This goes beyond the other demos

      Sparkling's other web previews render UI only — their native calls are inert in the browser. Here the in-heap route transitions actually work on the web, because that regime is pure Vue Router.

      Dynamic routes (the users bundle)

      The users bundle owns /users and the dynamic /users/:id. Tapping a user is an in-heap navigation with a route param, resolved entirely in this bundle's router. This preview boots at the bundle's own default route (/users).

      vue-router-mpasrc/pages/users/views/UserList.vue

      Cross-page navigation (MPA — use the QR / device tab)

      When router.push resolves to a route owned by another bundle (per the route manifest), the shim diverts it to router.open, which stacks a new native container. The previous page stays alive underneath, exactly like a native navigation stack.

      The <Go> web preview renders one bundle at a time and does not provide Sparkling's native method bridge (the spkPipe module), so router.open has nowhere to go. Tapping a cross-page button in the preview above therefore shows an inline notice ("native navigation unavailable here — open on device") instead of navigating. To exercise the full flow:

      • Scan the QR code and open it in Lynx Explorer (with Sparkling integrated), where router.open runs natively; or
      • run the local web-shell harness, which provides the method bridge and faithfully simulates the native container stack in a browser — see the example README.
      Why in-heap works but cross-page doesn't

      In-heap navigation is pure Vue Router running in the card's own JS heap — no native call — so it works in the preview. Cross-page navigation calls router.open, which needs a native host. sparkling-navigation exposes a pluggable RouterWebHost for embedders to supply one, but go-web's preview doesn't currently expose a hook to register it (or the spkPipe bridge) on its <lynx-view>. The web-shell, which owns the whole page, installs that host and bridge itself.

      How it maps

      Vue RouterSparkling
      route owned by the current bundlein-heap transition (SPA)
      route owned by another bundlerouter.open(<scheme>) — new container (MPA)
      router.back() past the local historyrouter.close() — pop the container
      history.statecarried across heaps inside the scheme URL
      history mode (createWebHistory/…)replaced by createHybridHistory

      For the complete traversal of Vue Router's feature set — what is supported, reframed, or limited under the MPA model — see the compatibility matrix.