Proposal for easier way to inject via DI into a view-model

I find Aurelia to be super efficient in terms of development, but there is one thing that takes up a few seconds of my time is dependency injection by needing to specify a constructor and use passed in injectables as params, then alias them to the current class.

To inject the Event Aggregator, you do this at present (I use static inject, but many use the inject decorator):

import { EventAggregator } from 'aurelia-event-aggregator';
 
export class MyViewModel {
    static inject = [EventAggregator];

    constructor(ea) {
        this.ea = ea;
     }
}

I am proposing a new decorator which does what the above code does, but looks like this:

@injectable(EventAggregator)
export class MyViewModel {

}

Under the hood, things would work the same. The decorator would simply be specifying the injected instances the same way @inject does and then would be creating new properties on the class itself.

The proposed decorator would have two arguments:

• injectable: For example EventAggregator - this is what you would pass to @inject() at present
• alias (optional): This would allow you to overwrite the convention of taking the injectable class name and making it camelCased. If this is not specified in the case of EventAggregator it would be injected into your class as: this.eventAggregator = eventAggregator

This is an example of an alias being provided (overriding default convention):

@injectable(EventAggregator, 'ea')
export class MyViewModel {

}

The above example would inject the Event Aggregator into the class as this.ea.

Why?

We already have flexible injection options and if you’re a TypeScript user, you can @autoinject and can hoist params on the constructor to the class, but not everyone uses TypeScript and it still doesn’t solve the problem of needing to define a constructor, in many cases just to pass DI instances into the class.

This is a case of me being lazy and wanting to clean up my view-models, because in many cases I never do anything inside of a constructor other than pass in DI instances.

Caveats

From what I can discern, there would be no issues with something like this. Although, I would be surprised if this hasn’t been thought of before and perhaps there are technical challenges with doing such a thing preventing a decorator like this ever being feasible. Happy to hear from others smarter than myself to chime in whether or not what I am proposing is crazy or possible.

[stsje]

What you are describing is property injection. I don’t like the idea of implementing a new injectable decorator, but maybe instead we could do property injection like we know it from autofac, guice etc.?

TypeScript will be easy enough, since it already knows the type of the object

export class MyViewModel {
  @inject eventAggregator : EventAggregator;
  @inject({ resolver: Lazy }) httpClient : HttpClient;
}

JavaScript you have to tell the decorator the type

export class MyViewModel {
  @inject(EventAggregator) eventAggregator;
  @inject({ type: HttpClient, resolver: Lazy }) httpClient;
}

[EisenbergEffect]

Closing this. There’s a community plugin that hooks into DI and adds property injection via the inject decorator. https://github.com/devaur/aurelia-property-injection