[Feature Request] Provide Default Constructor Injection Without Configuration Boilerplate

If we have a component that injects a service:

  constructor(private todoDataService: TodoDataService) {
  }

Then default the Angular bootstrapping / DI Factory to automatically create an inject this service as a singleton without further configuration. In other words we don't have to tell Angular that it needs to create a TodoDataService singleton. It does it automatically based on the decorators it finds in the application code. If the designer needs to they can override, but if not this just works.

Spring currently does this: https://spring.io/blog/2016/03/04/core-container-refinements-in-spring-framework-4-3

Good article on the related impact on testing and maintenance: https://spring.io/blog/2016/04/15/testing-improvements-in-spring-boot-1-4

Going through the root module documentation. It says this:

You tell Angular which components belong to the AppModule by listing it in the module's declarations array. As you create more components, you'll add them to declarations.

You must declare every component in an NgModule class. If you use a component without declaring it, you'll see a clear error message in the browser console.

So obviously Angular realizes that the developer has made a mistake and reports it in the console. What if instead angular's default behavior was to find and wire up the dependency for us?

Take for example the tour of HeroesDetailComponent. If that were imported directly into the AppComponent Angular could template markup and realize that it needs to dependency inject that component.

Right now Angular recommends that for each component the corresponding module also needs to be published. This also feels redundant. Since all this is written in typescript there has to be a way to compile out the needed meta data such that most of the module boilerplate can be eliminated leaving us with just @Component decorated component classes that the Angular compiler can scan to wire up the dependency graph.

I, too, have issues with the amount of boilerplate for injecting services. Currently, the Angular testing guide recommends setting up tests that require listing the dependencies four (4) times. I made a library to reduce this to a single list; its code name is SpyRing (because it contains a group of spies. Get it? Yeah, I'll keep my day job.)

I'm not sure whether to release SpyRing separately, or to suggest it be incorporated into Angular somehow. I'm hoping that, by describing what I have, I can get some feedback.

The 4 lists suggested by the guide are as follows:

A variable declaration for each service
Calling jasmine.createSpyObj for each service
Listing each service as a provider to TestBed.configureTestingModule
Assigning each service's variable to its value in the TestBed

When using SpyRing, the beforeEach block in this section of the guide would instead look like this:

let masterService: MasterService;  // Same as in guide

let spies = new SpyRing([
  { class: ValueService, methodNames: ['getValue'] },
]);

beforeEach(() => {
  spies.reset();  // internally calls createSpyObj for each spy described in SpyRing ctor

  TestBed.configureTestingModule({
    providers: [
      MasterService,
    ].concat(spies.getProviders()) // No longer need to list each spy here, but still flexible
  });

  masterService = TestBed.get(MasterService);

  // No need to assign spy objects here, as you can access them in tests via `spies.get`;
  // e.g., `spies.get(ValueService)` gives you the same object as `valueServiceSpy` in doc.
});

To add more services, just add a line for each when constructing SpyRing. That's it. (Of course, you still have to setup the spies' methods to mock return values, etc.)

So... Does this address (enough of) the boilerplate identified in this issue? Is there interest in incorporating all or part of this into Angular? What would that look like?

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.

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.

This is basically what providedIn syntax is capable of achieving.

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.}

Navigation Menu

Repository navigation

[Feature Request] Provide Default Constructor Injection Without Configuration Boilerplate #17188

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Feature Request] Provide Default Constructor Injection Without Configuration Boilerplate #17188

Description

Activity

oleersoy commented on Jun 2, 2017

oleersoy commented on Jun 3, 2017

LexVocoder commented on Aug 22, 2018

angular-robot commented on Jun 4, 2021

angular-robot commented on Jun 25, 2021

JoostK commented on Oct 6, 2021

angular-automatic-lock-bot commented on Nov 6, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions