docs(pos): note per-screen sandbox in Navigation API limitations#4438
docs(pos): note per-screen sandbox in Navigation API limitations#4438
Conversation
🚨🚨🚨 Docs migration in progress 🚨🚨🚨We are actively migrating UI extension reference docs to MDX in the
During this migration, please be aware of the following:
Doc comments in Examples that previously lived in this repo are being moved to the What should I do?
Thanks for your patience while we complete the migration! 🙏 |
|
This PR targets a stable release branch ( When you open the forward-port PR, include a line like this in its body so the Accepted formats (comma-separated for multiple):
If a forward-port isn't needed (e.g., the change is stable-only), you can remove the |
As of version 2025-10, each screen runs in its own isolated sandbox. This adds a Limitations bullet so developers know module-level state, closures, and singletons aren't shared across screens, and points to the state option / persistent storage as the supported way to pass data between screens.
b11b19f to
244c8e9
Compare
|
✓ Forward-ported in #4437. |
What
Adds a bullet to the Navigation API Limitations section noting that, starting in version
2025-10, each screen runs in its own isolated sandbox — state held in module-level variables, closures, or singleton instances isn't shared between screens.Why
Developers using
navigation.navigate()to move between screens have hit unexpected behavior when assuming module-level state, in-memory caches, or singletons would persist across screens. The current docs don't call this out. This PR adds a developer-friendly note pointing them at the supported way to share data: thestateoption innavigation.navigate()or persistent storage.Backports
This same note is being applied to the supported retroactive versions:
2026-07-rc— docs(pos): note per-screen sandbox in Navigation API limitations #44372026-04(this PR)2026-012025-10Preview