Programmatic navigation with use_pages=True silently fails — _pages_location needs to be public

[JohnBioinf]

Proposal

Two things need to happen: _pages_location should be a public export (e.g. dash.page_location_id, alongside dash.page_container and dash.page_registry), and the documentation needs to mention it in the use_pages guide, the dcc.Location reference, and wherever programmatic navigation is discussed.

The problem

When driving navigation from a callback with use_pages=True, you must output to the dcc.Location Dash bakes into page_container under the ID _pages_location. If you add your own dcc.Location and output to that instead, the browser URL updates, no error is thrown, and layout() on the target page is never called. Completely silent failure.

The fix requires either hardcoding "_pages_location" or importing a private constant (from dash.dash import _ID_LOCATION). Neither is acceptable. The hardcoding problem is already visible in dash-app-structure — a repo explicitly described as demonstrating good practices — which uses the raw string '_pages_location' directly.

This was already raised

Issue #2708 opened December 2023, labeled P2, a contributor endorsed it, assigned July 2024, unassigned a week later, reassigned November 2024, unassigned again August 2025. Two years, no movement.

How I found this

Migrating an existing app to use_pages=True. I kept my dcc.Location(id='url', refresh=False) and drove navigation via Output('url', 'pathname'). URL changed correctly, no errors, page content never updated. Found the cause only by reading the Dash source. Fix was three lines once understood.

Why does dcc.Location still exist?

With use_pages, you never need to instantiate dcc.Location yourself — the component already exists inside page_container. Adding your own is the trap described above. With some research it seems like its pure legacy. Before use_pages it made sense: you owned routing, you owned the component. Now Dash owns routing but dcc.Location remains in the public API unchanged, inviting exactly this migration mistake. At minimum _pages_location needs a public name. Whether dcc.Location warrants deprecation is worth discussing.

Sorry I think this sound a bit harsh but it gave me some proper head scratches. ❤️ Dash

[AnnMarieW]

Hi @JohnBioinf

Thanks for raising this again! I agree that it's a good idea to make the id for the pages_location public.

In the meantime, if you want to drive navigation from a callback, it is OK to add your own dcc.Location to your app. If you want it to navigate without refreshing the page, set dcc.Location(refresh="callback-nav") See this forum post for more information (it looks like this feature was not added to the docs)

https://community.plotly.com/t/sharing-examples-of-navigation-without-refreshing-the-page-when-url-is-updated-in-a-callback-in-dash-2-9-2/74260

dcc.Location should not be deprecated. It's still needed for apps that do not use the pages feature.

[camdecoster]

Thanks for the report! I'm going to close this issue as a duplicate of #2708. If you have additional comments, please add them there.