Conversation
| capabilities: Capabilities; | ||
|
|
||
| // Responsible for the creation of a RouteStateBucket. Returns a RouteStateBucket, defined by the manager implementation. | ||
| createRoute: (factory, args: CreateRouteArgs) => RouteStateBucket; |
There was a problem hiding this comment.
pro/cons of this being sync vs async?
would async route creation instead by a router-manager concern?
There was a problem hiding this comment.
This instantiates the bucket (which may or may not contain or even be what we'd consider a route instance). I've had a prototype where I did just in time creation of the actual route instance within the 'enter' hook and destroyed on 'exit' for a hypothetical route class where the lifetime of the instance was not singleton but instead only lasted while visiting a route.
This would indeed be a manager concern. 'createRoute' may seem a bit confusing in that sense but it's what the Router would need to handle routes through the manager API.
|
|
||
| The `createRoute` method on the Route Manager is responsible for taking the Route’s factory and arguments and based on that return a `RouteStateBucket` . | ||
|
|
||
| ***Note:** It is up to the manager to decide whether or not this method actually instantiates the factory or if that happens at a later time, depending on the specific lifecycle the manager implementation wants to provide.* |
There was a problem hiding this comment.
where could that happen?
There was a problem hiding this comment.
I think my other comment answered this already, but this would be left mostly to the route manager implementation. It does have to make sure the bucket has the info it needs for when the router calls the various lifecycle methods on the manager.
text/1169-route-manager-api.md
Outdated
|
|
||
| #### `getDestroyable` | ||
|
|
||
| The `getDestroyable` method takes a `RouteStateBucket` and will return the `Destroyable` if applicable. This can be used by the manager implementation to wire up the lifetime of the route. |
There was a problem hiding this comment.
lifetime linking typically happens during creation -- getDestroyable is for getting what was linked
There was a problem hiding this comment.
Yes indeed, reading this seems to indeed give the wrong impression. I'll revise the sentence a bit soon.
NullVoxPopuli
added
S-Exploring
pichfl
force-pushed
the
nickschot/route-manager-api
branch
from
3c87662 to
b633f2e
Compare
| capabilities: Capabilities; | ||
|
|
||
| // Responsible for the creation of a RouteStateBucket. Returns a RouteStateBucket, defined by the manager implementation. | ||
| createRoute: (factory, args: CreateRouteArgs) => RouteStateBucket; |
There was a problem hiding this comment.
We could likely specify factory as type object, since it needs to work with setRouteManager
| The minimal API for a Route Manager consists of `capabilities`, `createRoute` and a `getDestroyable` method. | ||
|
|
||
| ```typescript | ||
| interface RouteManager { |
There was a problem hiding this comment.
Clarify that this is NOT the full interface. It is expanded upon further into the RFC.
| signal: AbortSignal; | ||
|
|
||
| // A WeakMap of ancestor promises that can be used to await async ancestor behaviour. | ||
| ancestorPromises: WeakMap<RouteInfo, ReturnType<RouteManager.enter | RouteManager.update>> |
There was a problem hiding this comment.
This could be a function that takes a RouteInfo.
| ancestorPromises: WeakMap<RouteInfo, ReturnType<RouteManager.enter | RouteManager.update>> | ||
|
|
||
| // Retrieve the resolvedContext of an ancestor route. | ||
| getResolvedContext: (routeInfo: RouteInfo) => ReturnType<RouteManager.resolvedContext> | undefined; |
There was a problem hiding this comment.
This might need to be obligatory since the point of enter/update is to provide a context (even if its undefined).
Revisit why we did not tie this into the return value of the enter/update hook. These are tied to the specific navigation.
|
|
||
| ```typescript | ||
| interface RouteManager { | ||
| getInvokable: (bucket: RouteStateBucket) => object; |
There was a problem hiding this comment.
Glint should have a better type for this, something like ComponentLike<WithoutArgs>, check that.
| didEnter: (bucket: RouteStateBucket, args: NavigationState) => void; | ||
|
|
||
| // Similar to willEnter, but called on a Route that was also part of the previous navigation. | ||
| willUpdate: (bucket: RouteStateBucket, args: NavigationState & NavigationActions) => void; |
There was a problem hiding this comment.
willEnter/didEnter and didEnter/didUpdate may be identical. We need to verify if there is a reason for these to exist separately. Also explicitly check if the classic routes need it, in that case we could also put it on the classic capability.
|
|
||
| serializeQueryParam(bucket: RouteStateBucket, value: unknown, urlKey: string, defaultValueType: string); | ||
| deserializeQueryParam(bucket: RouteStateBucket, value: unknown, urlKey: string, defaultValueType: string); | ||
|
|
There was a problem hiding this comment.
We seem to be missing the functions that (de)serialize the model id from a passed model. Check if we need that here.
Would potentially not be needed if we fully deprecate passing non-strings to transitions/linkto's.
3 participants
Propose Route Manager API
Rendered
Summary
This pull request is proposing a new RFC.
To succeed, it will need to pass into the Exploring Stage, followed by the Accepted Stage.
A Proposed or Exploring RFC may also move to the Closed Stage if it is withdrawn by the author or if it is rejected by the Ember team. This requires an "FCP to Close" period.
An FCP is required before merging this PR to advance to Accepted.
Upon merging this PR, automation will open a draft PR for this RFC to move to the Ready for Released Stage.
Exploring Stage Description
This stage is entered when the Ember team believes the concept described in the RFC should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an
Exploringlabel applied.An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted Stage Description
To move into the "accepted stage" the RFC must have complete prose and have successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When the RFC is accepted, the PR will be merged, and automation will open a new PR to move the RFC to the Ready for Release stage. That PR should be used to track implementation progress and gain consensus to move to the next stage.
Checklist to move to Exploring
S-Proposedis removed from the PR and the labelS-Exploringis added.Checklist to move to Accepted
Final Comment Periodlabel has been added to start the FCP