includeRoutesInApplication option does not initialize the lazy engine routes

[AbhinavVishak]

ember new separate-route
cd separate-route
ember install ember-engines
ember generate in-repo-engine lazy-engine

Change the lazyLoading option to { enabled: true, includeRoutesInApplication: false } in lib/lazy-engine/index.js
Add a simple console.log('foobar') inside the buildRoutes function in lib/lazy-engine/addon/routes.js
ember s
go to localhost:4200/lazy-engine

The console log never shows up. Adding a breakpoint/logpoint on the define("lazy-engine/routes") triggers the define statement however.

[gtb104]

I created a reproduction (https://github.com/gtb104/lazy-engine).

In it I've defined:

  lazyLoading: Object.freeze({
    enabled: true,
    includeRoutesInApplication: false
  })

When the app loads in the browser, I get the following error:
Uncaught (in promise) Error: Assertion Failed: You attempted to generate a link for the "foo" route, but did not pass the models required for generating its dynamic segments. There is no route named lazy-engine.foo

What I expect to happen is the link to create successfully, and to properly route to the "foo" route when clicked.

[gtb104]

Clone the repo, start the server, then open a browser and go to localhost:4200. In the console you’ll see errors about it not being able to build the link to the `lazy-engine.foo` route. Kindest regards, Geoff

…

On Dec 5, 2020, at 10:46 AM, Michael Villander ***@***.***> wrote:  @gtb104 which are the steps to test it? should I access the route? http://localhost:4200/foo ? Please give us more details and then I'll try to debug it — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[villander]

@gtb104 @AbhinavVishak I'm not sure if this behavior is unexpected, given we don't any documentation clear about this attribute I can see in the codebase that we have a JS doc saying that when this attribute is false we don't want to promote the routes into the host.

What the behavior expected here? Is there another version of ember-engines where it worked as you expected?

ember-engines/packages/ember-engines/lib/engine-addon.js

Lines 589 to 595 in 92b84b3

	// The treeForEngine method constructs and returns a tree that represents
	// the engines routes.js file and its dependencies. This is used later to
	// promote the engines routes.js to the host.
	//
	// If the lazyLoading.includeRoutesInApplication option is false, we don't
	// want to promote the routes into the host.
	this.treeForEngine = function() {

[gtb104]

Perhaps I don’t understand the intent of PR425 (#425). It states: Introduces a new lazyLoading.includeRoutesInApplicationoption which enables lazy engines to output their routes.js file to a stand-alone file rather than bundling it into the hosts vendor.js file. This will enable engines to be discovered dynamically at runtime rather than requiring engines to be declared statically at build time. To me, that implies it doesn’t promote and bundle the lazily loaded engine’s routes at build time, deferring discovery until run time. We have an app with a frozen code base. One of the engines it uses is still under active development. What I envision setting includeRoutesInApplication to false would allow is for new routes to be added to the actively developed lazy engine, and the frozen parent app would be able to discover them dynamically at runtime. Kindest regards, Geoff

…

On Dec 5, 2020, at 11:05 AM, Michael Villander ***@***.***> wrote:  @gtb104 @AbhinavVishak I'm not sure if this behavior is unexpected, given we don't any documentation clear about this attribute I can see in the codebase that we have a JS doc saying that when this attribute is false we don't want to promote the routes into the host. What the behavior expected here? Is there another version of ember-engines where it worked as you expected? https://github.com/ember-engines/ember-engines/blob/92b84b33e4eb0bb5be64fb77578133986aa28d0c/packages/ember-engines/lib/engine-addon.js#L589-L595 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[villander]

This will enable engines to be discovered dynamically at runtime rather than requiring engines to be declared statically at build time.

For sure this behavior isn't supported to ember-engines, all things on manifest.json to load engines are created on build time.

could you please clarify the expected behavior of includeRoutesInApplication @rwjblue @dgeb? I never used it.

[villander]

@dgeb @bertdeblock any thoughts here?

[gtb104]

I've moved on to another project, and it looks like this is dead, so it can be closed.

[daniellubovich]

I'm also curious about the intended behavior of includeRoutesInApplication - anyone have insight into this? Maybe @mike183? Just a shot in the dark since I know it's been like six years.

[mike183]

@daniellubovich It's been a long time since I used ember-engines, but as far as I can remember, the intention of this feature was to allow an engine's route definitions to be included within it's own build output, instead of being bundled with the parent application.

This main motivator for this being to enable engines to be built in isolation, and also allow them to be side-loaded into an Ember.js application, without the engine itself needing to be present at build time of the parent application.

This effectively meant that you could use engines to dynamically extend an Ember.js application at runtime.

Hope that makes sense 🙂

[daniellubovich]

@mike183 Ah, okay that totally makes sense. I had assumed there was something in ember-engines that would automatically load up these routes files when the router encountered a lazy-loaded engine that hadn't yet been loaded. Sounds like that's not the case - this just handles keeping the routes separate at build-time, and I'd probably need to do something custom in my app to load them up at runtime?

Either way, this clears things up. Thanks for the reply!