Implement the Route Manager API (RFC #1169) - #21460
Open
evoactivity wants to merge 133 commits into
Open
evoactivity wants to merge 133 commits into
evoactivity wants to merge 133 commits into
Conversation
Introduce a Route Manager layer between the router and route base classes so the router drives routes through a well-defined manager interface instead of calling classic Route methods directly. This decouples the router from the classic Route and is the stepping stone toward alternative route base classes and a future router. Add the manager interface, capabilities, and registration, implement a ClassicRouteManager that encapsulates today's classic Route behaviour behind it, and make router_js dispatch lifecycle, rendering, model resolution, and the classic-interop surface through the manager.
This was referenced Jun 10, 2026
evoactivity
force-pushed
the
rfc-1169-route-manager
branch
from
June 15, 2026 08:44
37bd3e6 to
7582a9f
Compare
johanrd
added a commit
to johanrd/ember.js
that referenced
this pull request
Jun 15, 2026
…s on emberjs#21460 Reverts the outlet.ts compute-ref guard to the current ember-7.0.0 behavior, demonstrating that the @model-during-willDestroy instability (emberjs#18987) still reproduces on top of the Route Manager RFC implementation (emberjs#21460). The smoke-test job's '@model stability during route transitions' tests are expected to fail here. Not for merge.
8 tasks
refactor: add manager.getRoute(bucket)
…d through `setOutletState`
BobrImperator
force-pushed
the
rfc-1169-route-manager
branch
2 times, most recently
from
September 1, 2026 09:18
24dc292 to
5163e52
Compare
BobrImperator
force-pushed
the
rfc-1169-route-manager
branch
from
September 1, 2026 10:21
5163e52 to
47bbfce
Compare
BobrImperator
force-pushed
the
rfc-1169-route-manager
branch
2 times, most recently
from
September 8, 2026 14:42
1d418f9 to
8c96f1e
Compare
BobrImperator
force-pushed
the
rfc-1169-route-manager
branch
from
September 8, 2026 14:53
8c96f1e to
285a95f
Compare
cacheKey must be an element. The Cursor descriptor is an invalid key for renderer which fails during teardown
BobrImperator
force-pushed
the
rfc-1169-route-manager
branch
from
September 14, 2026 08:04
5eb0f1d to
0ece6cc
Compare
BobrImperator
force-pushed
the
rfc-1169-route-manager
branch
from
September 14, 2026 08:04
0ece6cc to
4ed25cb
Compare
ef4
reviewed
Sep 15, 2026
| const CAPABILITIES: InternalComponentCapabilities = { | ||
| dynamicLayout: false, | ||
| // Every route has its own template; `getDynamicLayout` supplies it. | ||
| dynamicLayout: true, |
Contributor
There was a problem hiding this comment.
This is concerning. dynamicLayout was created for backward compatibility and isn't really in-step with a modern understanding of components.
It exists because of the way a classic Ember component can set its own layout property to pick different templates on the fly.
I expect we don't really need this anyway because I think we're already making a new Component per route anyway. In that case you can replace getDynamicLayout with a one-time call to setComponentTemplate.
| wrapped: false, | ||
| willDestroy: false, | ||
| hasSubOwner: false, | ||
| hasSubOwner: true, |
Contributor
There was a problem hiding this comment.
This is surprising. Why do we need this?
| @@ -0,0 +1,219 @@ | |||
| diff --git a/dist/setup-rendering-context.js b/dist/setup-rendering-context.js | |||
Contributor
There was a problem hiding this comment.
Do we still need this patch, and if so: why is it safe for us to test against an @ember/test-helpers that users won't have?
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
5 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.
This is a big PR for a big feature.
Introduces a Route Manager layer between the router and route base classes so the router drives routes through a well-defined manager interface instead of calling classic Route methods directly. This decouples the router from the classic Route and is the stepping stone toward alternative route base classes and a future router. The classic Route behaves exactly as before, there are no changes to app authoring.
Three layers, top to bottom:
@ember/routingpublic re-exports of the authoring API@ember/-internals/routing/route-managersThe classic route manager and route manager infrastructurerouter_jsDrives the routes lifecycle through the manager, and owns the route manager contractWhy does the outlet have a legacy path?
A handful of tests directly set the outlet state, one in particular is testing something for liquid-fire. If there are addons or user code that expects to be able to create their own render state, they will not include the route wrapper and invokable we expect from the route manager, the legacy path path lets them continue working.
Query Params
The current implementation of query params is driven by the router, I have gated the parts that directly reach into routes behind the classic interop capability of route managers. I have left the "machinery" in place in the router. When we come to replace the router, a decision will need to be made if we bridge the classic router manager to use whatever new QP implementation we come up with, or if we fully migrate the router.js QP implementation to be fully encapsulated by the classic route manager.
RFC #1169