Skip to content

Provide an official way to access the module/injector for a route #25630

Closed

Description

@jonrimmer

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

When lazy-loading modules, the router faces the problem of how to inject providers that are registered in the child module from a root service, since providers in lazy-loaded modules are not added to the root injector.

The implementation solves this problem by keeping a reference to the lazy-loaded module in the router config, which it can use to lookup the child module's injector. However, this capability is kept internal to the router, which prevents apps that have the same requirement from using it.

Now, consider an app that includes its own DI tokens on lazy-loaded route definitions. E.g.:

{
  path: '/project/:projectId',
  component: ProjectComponent
  data: {
    breadcrumb: ProjectBreadcrumbProvider
  }
}

If ProjectBreadcrumbProvider is registered in the lazy-loaded module, then a global BreadcrumbService in the root module cannot inject it using the root injector. It needs the injector associated with the current route instead, but there is no official way to get hold of it.

Expected behavior

The Router should provide an official way to access the module/injector for a given ActivatedRoute. I would suggest running the same closestLoadedConfig() logic eagerly and including the resulting module as a module property on each ActivatedRouteSnapshot instance.

What is the motivation / use case for changing the behavior?

Apps currently have two options:

  • Replicate the logic from closestLoadedConfig() and rely on the internal _loadedConfig property. But relying on private APIs is not a good idea, as these could change or be removed in a later version.
  • Register these providers in the root scope, rather than the lazy module. But this bloats the root module and defeats the purpose of lazy-loading.

Neither of these is preferable. An official way to get the module/injector for a given route would solve the problem.

Environment


Angular version: 6.1.3

Activity

  1. added this to the needsTriage milestone on Aug 23, 2018
  2. modified the milestones: needsTriage, Backlog on Sep 4, 2018
  3. angular-robot commented on Jun 4, 2021

    @angular-robot
    Contributor

    Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

    Find more details about Angular's feature request process in our documentation.

  4. angular-robot commented on Jun 25, 2021

    @angular-robot
    Contributor

    Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

    We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

    You can find more details about the feature request process in our documentation.

  5. atscott commented on Jul 24, 2021

    @atscott
    Contributor

    Closing as duplicate of #24069

  6. angular-automatic-lock-bot commented on Aug 24, 2021

    @angular-automatic-lock-bot

    This issue has been automatically locked due to inactivity.
    Please file a new issue if you are encountering a similar or related problem.

    Read more about our automatic conversation locking policy.

    This action has been performed automatically by a bot.

  7. locked and limited conversation to collaborators on Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions