|
| 1 | +--- |
| 2 | +Stage: Accepted |
| 3 | +Start Date: 2021-02-12 |
| 4 | +Release Date: Unreleased |
| 5 | +Release Versions: |
| 6 | + ember-source: vX.Y.Z |
| 7 | + ember-data: vX.Y.Z |
| 8 | +Relevant Team(s): Ember.js |
| 9 | +RFC PR: |
| 10 | +--- |
| 11 | + |
| 12 | +<!--- |
| 13 | +Directions for above: |
| 14 | +
|
| 15 | +Stage: Leave as is |
| 16 | +Start Date: Fill in with today's date, YYYY-MM-DD |
| 17 | +Release Date: Leave as is |
| 18 | +Release Versions: Leave as is |
| 19 | +Relevant Team(s): Fill this in with the [team(s)](README.md#relevant-teams) to which this RFC applies |
| 20 | +RFC PR: Fill this in with the URL for the Proposal RFC PR |
| 21 | +--> |
| 22 | + |
| 23 | +# Align mount and route APIs |
| 24 | + |
| 25 | +## Summary |
| 26 | + |
| 27 | +Update the Ember `mount` API to accept a function argument which defines the Engine’s routes similar to how the `route` API works today. |
| 28 | + |
| 29 | +## Motivation |
| 30 | + |
| 31 | +Some Ember applications utilize in-repo ember-engines strictly for their lazy loading and code organization features and not for their isolation features. In this context the isolation actually causes some maintenance overhead and prevents build optimization. |
| 32 | + |
| 33 | +If isolation is not a requirement and all engines in an application are in-repo it makes more sense to define all of the routes at the application level in the router.js. |
| 34 | + |
| 35 | +## Detailed design |
| 36 | + |
| 37 | +The required change will be made to the `mount` method in [packages/@ember/-internals/routing/lib/system/dsl.ts ](https://github.com/emberjs/ember.js/blob/b35106e4d8471e396eb1ee5a5044b6bbe72fa069/packages/%40ember/-internals/routing/lib/system/dsl.ts#L176). A third argument will be added matching the method signature of the `route` method. |
| 38 | + |
| 39 | +```js |
| 40 | +mount(name, options, mountCallback) {...} |
| 41 | +``` |
| 42 | + |
| 43 | +If the argument is present and it is a function the route-map will not be resolved and the callback will be used in place of the resolved route-map. |
| 44 | + |
| 45 | +```js |
| 46 | +let engineRouteMap = null; |
| 47 | + |
| 48 | +if (!mountCallback) { |
| 49 | + engineRouteMap = this.options.resolveRouteMap(name); |
| 50 | +} |
| 51 | + |
| 52 | +if (mountCallback) { |
| 53 | + mountCallback.call(childDSL); |
| 54 | +} else if (engineRouteMap) { |
| 55 | + engineRouteMap.class.call(childDSL); |
| 56 | +} |
| 57 | +``` |
| 58 | + |
| 59 | +## How we teach this |
| 60 | + |
| 61 | +The alignment of the `route` and `mount` APIs should be easy to teach and is likely already inline with peoples mental model of the `route` API. |
| 62 | + |
| 63 | +This change also unlocks a more idomatic way of using in-repo engines when the use-case does not require isolation. |
| 64 | + |
| 65 | +The Ember-Engines documentation will need to be updated to include instructions for defining engine routes via the mount API. |
| 66 | + |
| 67 | +## Drawbacks |
| 68 | + |
| 69 | +One drawback is that this changes an existing public API and is something that existing Ember-Engines users may need to learn. |
| 70 | + |
| 71 | +## Alternatives |
| 72 | + |
| 73 | +Create an addon which extends the resolver to resolve route-maps from a custom location. |
0 commit comments