You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -243,7 +247,7 @@ Note: this is the full list of lifecycle events in a single transition between '
243
247
244
248
This sequence diagram only specifies the order of the hooks that are called as part of the Route Manager API, the dotted lines from the Router to the Browser are there for illustrative purposes only and are not specified as part of this RFC. Individual Route managers might express substates (such as loading states) as part of their own APIs, but they would have to do that within the constraints of the Route Manager API hooks.
245
249
246
-
In the above diagram the `enter()` is called before the `getInvokable()` for a given route. The promise returned from `enter()` is exposed to `getInvokable()`, so a manager may either await it (to gate rendering on data) or ignore it (to render immediately and coordinate loading inside its wrapper).
250
+
In the above diagram the `enter()` is called together with the `getInvokable()` for a given route. Both are executed at the same time and are required to resolve before route info is marked `resolved`.
247
251
248
252
### Capabilities
249
253
@@ -257,23 +261,91 @@ When the `classicInterop` capability is set to `true` the Route Manager will hav
`getRouteWrapper` returns a component that calls the route's invokable. The router curries `@Component` (the invokable), the context, and the bucket onto it. The wrapper should be stable across renders so that the rendering layer can use identity to determine when to tear it down.
375
+
`getRouteWrapper` returns a component that calls the route's invokable. The router curries `@Component` (the invokable), the context, the outlet, and the bucket onto it. The wrapper should be stable across renders so that the rendering layer can use identity to determine when to tear it down.
306
376
307
-
`getInvokable` returns the component for the current route. It receives the in-flight `enterPromise` so the manager can choose whether to await data before resolving, or to resolve immediately and defer loading-state handling to the wrapper. The promise is async to allow `await import()` for lazy-loaded route modules, and is never exposed elsewhere on the manager-facing API.
377
+
`getInvokable` returns the component for the rendered route. The promise is async to allow `await import()` for lazy-loaded route modules, and is never exposed elsewhere on the manager-facing API.
378
+
379
+
-`@Component` represents a route for the currently rendered level
380
+
The wrapper component can curry new args onto it. The args would typically come from the `@bucket` which is both an identity and a data holder of a given route.
381
+
-`@outlet` is effectively a `@Component` of a child route
382
+
The wrapper is not allowed to add new args to it. Given it's possible to zebra-stripe route-managers, the contract for `<@outlet />` might be different to what you expect at a current level.
383
+
-`@context` is the resolved value of what `manager.enter()` returns.
384
+
-`@bucket` is the object returns from `CreateRoute()`
308
385
309
386
## How we teach this
310
387
@@ -328,15 +405,14 @@ This will require the Classic Route Manager to do some more elaborate internal w
328
405
329
406
A previous version of this RFC had a sync version of the `getInvokable()` function on the Route Manager API. This was changed to give a slightly better developer experience to allow people to absorb asynchronous imports of modules. Note: this is not intended to have any implications on the `enter()` hook and the async data loading is never intended to happen during the `getInvokable()` promise lifecycle.
330
407
331
-
We do not strictly need to have an async `getInvokable()`because you could always return a sync invokable that managed the async internally, i.e. using a resource-style pattern. As these APIs are quite low-level it doesn't really matter which way we lean on this decision since the complexity will never leak into Ember App Developer ergonomics.
408
+
The Framework has an opinion over when `getInvokable()`should load and resolve however. Users are given a way to dynamically load contents of a given route but the Framework owns it.
332
409
333
410
### Merging enter() and getInvokable() hooks
334
411
335
412
Comments on this RFC proposed that we could unify the `enter()` and the `getInvokable()` functions. We are explicitly not merging those two functions because the `enter()` hook returns context (usually from data-loading) which is entirely separate from the concerns of `getInvokable()`.
336
413
337
-
Separate functions also allow for more flexible implementations of the manager lifecycle, for example you could have a manager that always resolves `getInvokable()`immediately and does not gate rendering on the result of `enter()`, or you could have a manager that waits for the result of `enter()` before resolving `getInvokable()`.
414
+
It's worth noting that the promise returned by the `getInvokable()` is never exposed to any route via the Route Manager API, and will be an internal concern of the Router itself. The promise returned from `enter()`is exposed to child routes via the `getAncestorPromise()` function so they can await the result to get the context of parent routes.
338
415
339
-
Also, it's worth noting that the promise returned by the `getInvokable()` is never exposed to any route via the Route Manager API, and will be an internal concern of the Router itself. The promise returned from `enter()` is exposed to child routes via the `getAncestorPromise()` function so they can await the result to get the context of parent routes.
340
416
341
417
## Unresolved questions
342
418
@@ -383,21 +459,6 @@ The model hooks are an RSVP Promise chain handled by router_js. We can put them
383
459
384
460
---
385
461
386
-
#### Updating the model for an existing route mapped to manager hooks:
387
-
388
-
-`willUpdate` (leaf-most)
389
-
-`willTransition` event
390
-
-`routeWillChange` event, router service
391
-
-`update`
392
-
-`beforeModel`
393
-
-`model`
394
-
-`afterModel`
395
-
-`didUpdate` (leaf-most)
396
-
-`resetController` (conditionally, if model return value changed)
397
-
-`setupController` (conditionally, if model return value changed)
398
-
-`didTransition` (event, leafmost)
399
-
-`routeDidChange` event, router service
400
-
401
462
#### Mapping of existing events and methods to the new API
0 commit comments