Dependency Injection: create a new instance of the injectable on each call.

[ievgennaida]

🚀 feature request

Relevant Package

Angular core, IVY, DI

Description

I would like to have in my application some kind of 'commands/actions' that suppose to execute some logic and hold the state.

Example usage:

Users can execute different commands from the component and also undo.
Each command should store some state in order to perform some action and undo the action.

I would like to have something like:

@Injectable({
  providedIn: "transient",
})
export class Command1{ 
    constructor(logicExecutor:Service){ }
    uniqueCommandState = ''
    do(commandState:string){
       this.uniqueCommandState = commandState;
      // Call here few services. to perform BL 
      this.logicExecutor.do_something();
    }

}


// Then I can call it from the component:
@Component({
  selector: "app-context-menu",
  templateUrl: "./context-menu.component.html",
  styleUrls: ["./context-menu.component.scss"]
})
export class ContextMenuComponent
  constructor(private injector: Injector) {}
  
  buttonClick() {
      // Use angular DI to help instantiate command with various services:
      const uniqueCommand = injector.get(Command1);
      uniqueCommand.do('id');
     // I would expect the each command will be unique, stored to be handled later. Ex: undo
  }

}

Describe the solution you'd like

I would like to have a mode for the Injectable attribute to allow create new instance on each request.
Another option is some kind of flag to resolve any class constructor arguments with the registered services:

const uniqueCommand = injector.get(Command1, ... InjectFlags.ResolveInstanse)

Describe alternatives you've considered

Remove the created instance from a cache:

    const result = this.injector.get(Command1);
    (this.injector as any)?.records?.delete(Command1);

So far, there are some limitations.

See how it's works in .NET (transient state):

https://stackoverflow.com/questions/38138100/addtransient-addscoped-and-addsingleton-services-differences

[Airblader]

Can't this trivially be achieved by modelling your command as a plain class and having a "factory injectable" with some create method that creates an instance, passes the dependencies to it and then returns it?

[ievgennaida]

Can't this trivially be achieved by modelling your command as a plain class and having a "factory injectable" with some create method that creates an instance, passes the dependencies to it and then returns it?

@Airblader I have checked docs but I cannot find how to resolve this in a simple manner.

If you are passing arguments to the instance manually this is not a dependency injection anymore and you are losing part of the beauty and convenience of the pattern.

In the case of a factory, you are forced to refactor the code when services injected to the command constructor (For my example It can be also more than 10+ services for each command, that I need just to pass thru).

So would be great to have an option just to create a new instance without manual work,,,

[jnizet]

@ievgennaida if you use injector.get() to get an instance of your command, it's not DI either. I don't see how a custom-made factory wouldn't solve your issue. Let's write an example to make it clearer:

export class Command1{ 
  constructor(logicExecutor:Service){ }
  uniqueCommandState = ''
  do(commandState:string){
    this.uniqueCommandState = commandState;
    // Call here few services. to perform BL 
    this.logicExecutor.do_something();
  }
}

@Injectable(
  providedIn: 'root'
)
export class CommandFactory {
  constructor(private logicExecutor: Service, private other: OtherService, private yetAnother: YetAnotherService) {
  }

  createCommand() {
    return new Command(this.logicExecutor);
    // and you can store it somewhere if needed before returning it
  }

  createOtherCommand() {
    return new OtherCommand(this.other, this.yetAnother);
  }

  // ...
}

// Then I can call it from the component:
@Component({
  selector: "app-context-menu",
  templateUrl: "./context-menu.component.html",
  styleUrls: ["./context-menu.component.scss"]
})
export class ContextMenuComponent
  constructor(private commandFactory: CommandFactory) {}
  
  buttonClick() {
      // Use angular DI to help instantiate command with various services:
      const uniqueCommand = commandFactory.createCommand();
      uniqueCommand.do('id');
  }
}

This doesn't need any specific support from Angular, it still hides the dependencies of the commands from the component, it still uses DI to manually inject the services in the commands, making them easy to test with mocks, and it still uses DI to inject the factory in the component, allowing you to inject a mock factory creating mock commands in tests.

[ievgennaida]

@jnizet Your assumption about the DI is wrong!
DI does not stop being DI if you are calling it with injector.get(). Does not meter where you are resolving your dependencies in a constructor or in a code. The main benefit that arguments are automatically resolved.
And this is widely used in backend frameworks like .NET and etc.

I have described above all the problems that will come with the factory.

But I will also put comments in the code provided:

1. I have a huge amount of commands.
2. Each command can have its own services referenced.

Problems with the factory:

1. You should manually pass and refactor code on each constructor argument call. This is not DI anymore. In the same manner, you can just instantiate your command in a code, but in this case each component will have unrequited service injections only to pass to a command.

2. You should refactor factory code and command calls each time command code is changed, with a simple DI that can generate instance you can avoid that! You are losing the maintenance convenience that default DI is providing.

3. Extra code that is not really required.

4. You have provided example with the factory that can create two command. In this case you are injection huge amount of services and this will create unassigned wiring of services even if they are not used. (ex: the only command1 is used in the component, all other reference and initialization was unrequired)
   To make it a bit less ugly you have to create factory for each command just to solve this simple task.

export class Command1{ 
 // Services list can be long, it's convenient to resolve this with the core DI instead of manual work.
  constructor(service1:Service, service2:Service2,service3:Service3,service4:Service4,service5:Service5){ }
  uniqueCommandState = ''
  do(commandState:string){
    this.uniqueCommandState = commandState;
    // Call here few services. to perform BL 
    this.logicExecutor.do_something();
  }
}

export class Command2{ 
 // For each command services list can be unique. 
  constructor(service6:Service6, service7:Service7,service8:Service8,service9:Service9,service10:Service10){ }
  uniqueCommandState = ''
  do(commandState:string){
    this.uniqueCommandState = commandState;
    // Call here few services. to perform BL 
    this.logicExecutor.do_something();
  }
}

// You have to write extra code for each command, only because of the core limitation.
// This is a hack while you need just to bypass the arguments. The factory examples provided was more about to alter arguments.
@Injectable(
  providedIn: 'root'
)
export class CommandFactory {
 // In this example you have to reference tons of services for all the commands!  This is creating unassigned wiring of services!
  constructor(service1:Service, service2:Service2,service3:Service3,service4:Service4,service5:Service5, service6:Service, service7:Service2,service8:Service3,service9:Service9,service10:Service10) {
  }

  createCommand() {
   // This is not dep injection anymore. You have to refactor this code on every command arguments change.
    return new Command(this.service1, this.service2, this.service3, this.service4, this.service5, this.service6);

  }

  createOtherCommand() {
    return new OtherCommand(this.service7, this.service8, this.service9, this.service10);
  }

 
}


@Component({
  selector: "app-context-menu",
  templateUrl: "./context-menu.component.html",
  styleUrls: ["./context-menu.component.scss"]
})
export class ContextMenuComponent
  constructor(private commandFactory: CommandFactory) {}
  
  buttonClick() {
      // Use angular DI to help instantiate command with various services:
      const uniqueCommand = commandFactory.createCommand();
      uniqueCommand.do('id');
  }
}

What I am proposing is just a one-liner argument to solve this problem.

@Injectable({
  providedIn: "transient",
})
export class Command1{ 
    constructor(logicExecutor:Service){ }
    uniqueCommandState = ''
    do(commandState:string){
       this.uniqueCommandState = commandState;
      // Call here few services. to perform BL 
      this.logicExecutor.do_something();
    }

}


// Then I can call it from the component:
@Component({
  selector: "app-context-menu",
  templateUrl: "./context-menu.component.html",
  styleUrls: ["./context-menu.component.scss"]
})
export class ContextMenuComponent
  constructor(private injector: Injector) {}
  
  buttonClick() {
      // Use angular DI to help instantiate command with various services:
      const uniqueCommand = injector.get(Command1);
      uniqueCommand.do('id');
     // I would expect the each command will be unique, stored to be handled later. Ex: undo
  }

}

[Airblader]

A practical problem would be, however, how the framework can decide at which point the onDestroy hook can be run?

Also this comes at the cost of framework bundle size which the Angular team is trying to prevent. Other features that have idiomatic solutions are rejected because of that and I don't really see how this would be any different. You only pass the dependencies from the factory to the constructor in a single place. If commands share dependencies you can even just create an abstraction for that as well.

[ievgennaida]

This is different only in the sense that it provides a feature that gives you more flexibility and supported by other frameworks.

I would assume that this kind of dependency can be instantiated only from injector.get and in this case it can be excluded from the lifecycle workflows.

"Also this comes at the cost of framework bundle size which the Angular team is trying to prevent. "
All code is there, this fix can be one or two liners I guess.

Might be a solution to allow a flag for injector.get to resolve dependencies for the constructor of the class, this will also mean that the created instance is excluded from the lifecycle.

[Airblader]

I would assume that this kind of dependency can be instantiated only from injector.get

This sounds extremely surprising and inconsistent to me. Why should I not be able to inject this in a constructor like anything else?

in this case it can be excluded from the lifecycle workflows.

This will also make for surprising and therefore very error-prone behavior. There's no good reason that the lifecycle of injectables should depend on how they are provided.

It is possible that the lifecycle of the injectable could be attached to that of the injector. This isn't exposed publicly as an API, though, so I don't know how this looks internally in Angular and how much trouble it'd be, but it'd be the very least I would expect the framework to handle to fulfill the current contract for injectables in some sensible way. However, I suspect this could be a problem for what you're doing.

Might be a solution to allow a flag for injector.get to resolve dependencies for the constructor of the class, this will also mean that the created instance is excluded from the lifecycle.

IMO this is even worse by breaking the responsibilities. Whether a lifecycle hook runs would now depend on how the caller injects it, so the injectable has no control or knowledge over whether it has a lifecycle.
Any injectable should trust that its hook will get run by the framework at the appropriate time.

Personally I think the downside of the factory pattern isn't nearly as big as you're making it out to be. Yes, changing dependencies also means changing the factory. But that's a trivial change to make, restricted to one very specific spot, and it's entirely compile time safe. It's not really any different from having to update unit tests, too.

[ievgennaida]

Might be trivial to change (depends on a project) but unnecessary, that why this option exists in other frameworks.

[angular-robot]

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.

[Airblader]

Random thought of the day, this feature would allow a fairly simple way to support #10185 at least for OnDestroy (but not most other hooks).