Prepare for addition of engine-specific router service about ember-engines HOT 5 CLOSED

Sounds exactly like what I recall from the meeting. 👍🏼

I have a few minor notes though:

• Register a new router service that proxies all its methods to the host's router service. Every method invocation that's passed should include a deprecation warning.

Unconditionally creating a proxy router service in every engine may cause unintended side-effects, e.g. some addon or user code may check for the existence of a router service and use different adapters then. Considering that addons that deal with routing need to special-handle engines in one way or another, if they want to be compatible, the likelihood is not zero, that the mere presence of a router service could change the behavior.

On the other hand, this may be super-edge-case-y, SemVer-lawyering-wise still okay and not even a real issue.

We could however only setup the proxy router service, when a service with that name is actually injected into the engine.

Which is a nice segue into my next nitpick:

[...] proxies all its methods to the host's router service [...]

This would not work for these two scenarios:

• Engine implements and registers the router service by itself. It is not an external injection.
• The host remaps / aliases the router service name and e.g. injects mock-router as router.

  engines = {
    superBlog: {
      dependencies: {
        services: [
          // name in superBlog engine: 'store'
          // name in host: 'store'
          'store',
  
          // name in superBlog engine: 'router'
          // name in host: 'mock-router'
          { 'router': 'mock-router' }
        ]
      }
    }
  };

Instead of always "blindly" proxying to the host's router service, I would prefer, if we could somehow "wrap" the actual router service instance, when it gets registered / injected. This way we would:

• only make router available in engines, where it already was available
• don't accidentally break custom interfaces introduced by users, who use some sort of custom router service, i.e. not the app-router.

For instance, at @ClarkSource we've been using our own make-shift engine-specific router service as router inside many engines for 2½ years now, basically ever since I opened #587.

We should also consider allowing an experimental build flag to allow usage of an alpha engine-specific router which we can iterate upon starting in 0.9. This approach should allow opt-in usage of a router service similar to that in #669 for developers who are willing to experiment and endure some breaking changes.

Big 👍🏼.

from ember-engines.

Ya, sounds like a good summary here to me.

from ember-engines.

Great summary, thanks @dgeb

But I think you can put here how the new router service will work in js and template files and the relation with *External methods to give more context

from ember-engines.

Closing now, since this has effectively been resolved via the deprecation introduced in #764. As discussed in that PR, the assumption about automatic injection of the host's router was incorrect. This is greatly simplifying, since we only needed to deprecate injection of the router service and no longer need to deal with the complexities of a proxy router (which @buschtoens mentions above).

from ember-engines.

The one piece left todo is this:

We should also consider allowing an experimental build flag to allow usage of an alpha engine-specific router which we can iterate upon starting in 0.9.

This can be handled in a subsequent PR.

from ember-engines.