Support for injections of functions that return litteral objects

[alexis-valois]

Hi,

I know some JavaScript developpers dislike the use of the "class" and "this" keywords. It has to do with the fact that "this" could lead to some difficult to debug behaviours when passing an instance method to a callback without binding "this" to the class in the constructor, beforehand.

There's other ways to create Object that would not need the use of those keywords.

Here's an example :

// LiteralConsumer.ts

import { SomeService } from "./SomeService"
import { Consumer } from "./Consumer"

// no "class" or "implements" required
export default function(someService: SomeService ): Consumer { 
  function somePrivateStuff() {
   ...
  }
  return {
    consume: (): Promise<string> => {
         // no "this"
          somePrivateStuff();
          return someService.doSomething();
    }
  }
}

// usage

import LiteralConsumer from ./LiteralConsumer";

const service = ...;
// no "new" required
const instance = LiteralConsumer(service); 

Here, the function's argument serves as the object's construction dependencies injection hook, and the TypeScript type "Consumer" refers to its interface.

(Note the absence of "new")

The JavaScript closure mechanism makes it possible to use the returned method "consume" anywhere, even if it references the "someService" variable, as it is accessible in its declaration scope.

(Note the absence of "this")

Also, the "return" statement gives us an elegent solution to export only public stuff, making the prive ones "actually private", even at runtime.

At the moment, i don't think inversify's able to bind such "function object", because the binding interfaces expects "newable" arguments.

Ex :

container.bind<Consumer>(TYPES.Consumer).to(LiteralConsumer ).inSingletonScope();

The above line would lead to "Argument of type '(someService: SomeService) =>Consumer' is not assignable to parameter of type 'Newable'."

Is there a plan to support this kind of bindings in the near future, or have this already been discussed ?

Thanks

[notaphplover]

Hey @alexis-valois, it would definitively be a great feature to have. I'm currently focused on internal refactors and fixing bugs, but I think it would make a lot of sense to implement this feature in the future.

[alexis-valois]

Great ! If you have time to give me some hints and orientations in the codebase, maybe i could try propose a PR for it ?

[notaphplover]

I'm afraid this is not an easy task to implement at all.

First of all, we should think the way we name this feature to not to collide with existing features. Unfortunatelly, Factory and Provider are already features. I understand this is conceptually a Builder.

The first steps are sort of easy:

• Update Binding to support builder binding values.
• Update BindingToSyntax to support a builder binding.

After that, the planner should be adjusted to handle this bindings.

The most challenging part is to build a resolution algorithm. We can probably reuse (and therefore make an abstraction) from the current resolution algorithm for instances (it's basically the same but the final step you invoke the builder instead of calling a contructor).

It's really a tedious part and the core of the library is being refactored, so we'd be probably building something to be rebuilt.

For such a reason I do prefer to do it after the refactor: it's going to be way easier that way

[alexis-valois]

Understood. Would you like me to document an issue in the meantime with all those details and requirements so we keep track of it ?

[notaphplover]

Indeed, I'd be great if you submit a feature request.