A recent update to the dependency injection makes the
autoinject (and i guess others) decorator incompatible with TypeScript abstract classes.
This breaks an inheritance-based scenario common in our application:
- we use abstract, generic classes for viewModels with high-level shared functionality (e.g. a generic form control, a generic detail page…). These use
@autoinjectand have a defined constructor with a sometimes large number of arguments: for reference the generic detail page constructor currently has 9 arguments, all services (Aurelia’s or ours) like EventAggregator, Router and BindingSignaler
- the concrete viewModels inherit (
extends) from these abstract base viewModels. Most of the time there is no need to override the default constructor as it covers everything, so the concrete viewModel has no explicitly defined constructor and no
We have currently downgraded to 1.4.2 (and aurelia-validation to 1.4.0), but this is obviously not a long-term solution.
To fix this problem in our application, we could:
- make the abstract classes not abstract. This would cause no concrete issues but defeats the semantic purpose of using abstract in the first place.
@autoinjectto the last level of concrete classes. This is arguably more semantically correct, but most of the time it would be redundant and prone to being forgotten (in the transition stage, at least).
However, before rushing to change such a large number of files I would appreciate to know if our structure is sound enough, and if so if it is enough of a common / useful use case to warrant some kind of consideration in the aurelia-dependency-injection type definitions.
If this is relevant, we currently have to target ES5.
Furthermore, with 1.5.0 we get this error while compiling:
This could be related to our version of TypeScript, however (I am decently sure it is 3.1 which is quite outdated).
…/node_modules/aurelia-dependency-injection/dist/aurelia-dependency-injection.d.ts(139,162): error TS2536: Type ‘number’ cannot be used to index type ‘TArgs’.