Implement the Route Manager API (RFC #1169) - #21460
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.
37bd3e6 to
7582a9f
Compare
…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.
refactor: add manager.getRoute(bucket)
…d through `setOutletState`
1d418f9 to
8c96f1e
Compare
8c96f1e to
285a95f
Compare
cacheKey must be an element. The Cursor descriptor is an invalid key for renderer which fails during teardown
5eb0f1d to
0ece6cc
Compare
0ece6cc to
4ed25cb
Compare
| const CAPABILITIES: InternalComponentCapabilities = { | ||
| dynamicLayout: false, | ||
| // Every route has its own template; `getDynamicLayout` supplies it. | ||
| dynamicLayout: true, |
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.
There was a problem hiding this comment.
This appears to have been a leftover from the time when the current outlet-component didn't exist. This is now replaced by a setComponentTemplate in a makeRouteTemplate helper
| wrapped: false, | ||
| willDestroy: false, | ||
| hasSubOwner: false, | ||
| hasSubOwner: true, |
There was a problem hiding this comment.
This is surprising. Why do we need this?
There was a problem hiding this comment.
This appears to have been an another leftover... initial version when migrating from the -outlet helper needed this.
Right now the outet-component is the only place that needs this capability
| @@ -0,0 +1,219 @@ | |||
| diff --git a/dist/setup-rendering-context.js b/dist/setup-rendering-context.js | |||
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?
There was a problem hiding this comment.
well yes, but the patch keeps the fallback for pre-route manager testing so it should be ready to actually open upstream
@BobrImperator are you able to open that PR with the changes?
There was a problem hiding this comment.
This was there to highlight the need for this change since the removal of RootView crashed the test suite. There's a draft PR open for the test-helpers already which I'll update shortly.
ae112e2 to
aa3753d
Compare
aa3753d to
d00dfe1
Compare
this was a leftover from the time when the wrapper/outlet components weren't static but dynamic
6043e52 to
6bd55a8
Compare
this is now handled by the outlet-component wrapper
5 participants
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