uni-router v1.10 Ships a Global Event Bus That Gives Every Navigation Method a Bidirectional Channel

Any uni-app project that uses replace or relaunch for login flows, stack replacement, or app resets now gets the same inter-page communication that was previously exclusive to push. The sticky cache removes a class of flaky, timing-dependent bugs that are hard to reproduce and harder to fix without a framework-level solution.

The native uni-app EventChannel only works with navigateTo, leaving replace and relaunch navigations without a way to pass data between pages. uni-router v1.10 introduces a built-in communication manager that wraps uni.$emit/$on, assigning a unique navigationId to every navigation so push, replace, and relaunch all return a usable eventChannel. The same channel is exposed to RouterLink’s navigated event, unifying the API across every navigation method.

A sticky event cache inside UniEventChannel solves the long-standing race condition where an emit fires before the target page’s setup registers its listener. Emitted data is always cached, and any late-arriving on or once registration receives it asynchronously via a microtask. The cache persists until the channel is destroyed, so even a once listener registered later gets the last payload.

The target page retrieves its channel through a new usePageChannel() composable that reads a __nav_id from the URL query, making the channel survive H5 refreshes. When no navId is present—such as a direct browser visit—the API returns a noopChannel so callers never need null checks. Channel cleanup is automatic in onUnmounted, preventing memory leaks from abandoned listeners.

A preference surfaces for Flutter's promise-based navigation pattern, where a push returns a result directly, over the event-bus workaround uni-router provides. The limitation is acknowledged as a platform constraint — uni-app's own API simply doesn't offer that capability.