Alternative to injecting directly into dependent objects?

[geekdave]

John E:

I like the DI, but have a little visceral reaction to having the DI framework mess with your objects directly rather than having something passed in or maybe a single object that is populated with a value. For example, having something like "this.injector.myUserModel" rather than "this.myUserModel". It just seems very easy to have field or method name conflicts.

Dave C:

I felt conflicted about this, myself. But I thought that by declaring the injected variables right at the top of the file, it would be very clear which properties are expected to be injected. Furthermore if we have a convention of descriptive variable names, like "quoteModel" I see it hard for there to be a conflict with a local variable. Let's discuss more though...

To argue both sides of this point (and to contradict my earlier argument), perhaps when injection occurs, we could overwrite the declared "injections" array (which is only used once to declare what the injection names are) with an injections map that maps each injection name to the injected object instance.

This would serve to clean up a superfluous array, and would be safer to use without the worry about variable name conflicts.

I only worry about the verbosity of using this.injections.quoteModel... On the other hand it makes it very easy to tell which objects came from injections...

John E:

If it's just the verbosity, then a must shorter name could be used (e.g. this.gi.quoteModel) where gi stands for Geppetto Injector or something like that.

[creynders]

For example, having something like "this.injector.myUserModel" rather than "this.myUserModel".

I'd definitely advise against using injector, since people will expect it to contain an Injector instance.
IMO DI should always be something extraneous, so that when a class is reused in a non-DI project you don't need to change a single character on the class, simply wire it differently since there's no auto-DI.

we could overwrite the declared "injections" array

It's a possibility, but I'm always hesitant about reusing a config object for something else.

TBH I see no problems with messing with the objects directly, since the wiring's explicitly declared. It's pretty common practice. Would the wiring be implicit, I wouldn't even consider automatic injection in object properties.

[creynders]

Thinking some more about this, maybe it's a good idea to allow for an optional mappings parameter to all wire* methods, which simply allows you to map a named dependency to a property name. Something like this:

//wiring of dependee
context.wireSingleton( 'userModel', UserModel);

//wiring of depender
context.wireView( 'loginView', LoginView, { 'userModel': 'loggedinUser' });

//LoginView
initialize: {
    this.loggedinUser = undefined;
}

BTW, just to clarify:

Would the wiring be implicit

I meant if the wiring was automatically setup by class name or filename.

[geekdave]

which simply allows you to map a named dependency to a property name.

It's an interesting option. I'm trying to think of the use case for this. In your example, I'm imagining a view that already has a property called userModel, and therefore the developer knows there would be a conflict if they needed to inject a property as this.userModel. So they "re-map" that dependency so it's injected as this.loggedinUser. Is that the use case you had in mind?

I'd definitely advise against using injector

Agreed on the possible confusion here. But for the sake of this discussion, let's separate the notion of what the injections object container is named, vs. whether there should be an injections object container at all.

so that when a class is reused in a non-DI project you don't need to change a single character on the class, simply wire it differently since there's no auto-DI.

I would argue that it would be just as easy to accomplish this if your dependencies were referenced as:

this.userModel vs. this.[someObject].userModel ...such as... this.$g.userModel

Using such a component outside of a DI container, would it not be just as easy to write someObject.$gi = { userModel: xyz } as it would be to write someObject.userModel = xyz?

Doing it this way would seem to eliminate the need to have custom re-mappings of named dependencies to different property names, since everything would be referenced from a single injected object "container". As for what to name that container (injections, inject, gi, $g, etc...) that's another discussion. :) But what about the concept?

[creynders]

I'm trying to think of the use case for this

It's mostly useful when reusing classes created in a non-Geppetto project. With the switchboard approach (=the extra parameter to all map* methods) there's no need to modify the class itself, even if its outlets/injection points aren't "correctly" named.
And the use case you describe as well, of course.
Also, it allows for a fully explicit declaration of all wiring.

I would argue that it would be just as easy to accomplish this if your dependencies were referenced as: [...] this.$g.userModel

Yes, of course. It's not about complexity, but about

1. how it influences the way you write your code. Let's say you have a class which creates an instance of a Foo class. You store it in a property foo. Later on, you realize it would be better to have the Foo instance injected. Then either you'll be replacing all references to this.foo with this.$g.foo or you'll transform this.foo to a getter. It's not a really big deal, but the choice of framework does influence your code, which is a no-no IMO. (In JS there's already too much of that going on with RequireJS and Backbone)
2. and it's problematic when going the other way too: let's say you had a Foo instance injected, but at a certain point you want to refactor the class to compose the Foo instance self. You'll be rewriting all this.$g.foo to this.foo or even worse, if you're really lazy, you'll be doing this.$g.foo = new Foo() which is a huge can of worms.
3. it creeps towards property chaining, e.g. this.$g.foo.bar.baz.qux

Again, it's not a huge problem, but for me (and probably others too) it would lead to some extra work, since I'd be writing explicit getters for all injections to avoid referring to a $g object in my code.

let's separate the notion of what the injections object container is named, vs. whether there should be an injections object container at all.

Yes, absolutely. Speaking of which. I'm not a fan of $g either since by convention I'd expect it to be a JQuery reference to a DOM node.

[creynders]

Personally, if we add the switchboard object to all map* methods, I'd drop the injections array in all my classes and setup all wiring using the switchboard. It's clean, explicit and allows your dependers to be completely wiring-agnostic.

[geekdave]

I think the decision of whether to use the switchboard approach vs. injections array should be left to the project. I can see advantages for both cases. For my team, we like the injections array. Will your solution support both as it's currently implemented?

[creynders]

Ah yes, it supports both. Renamed to wiring, see https://github.com/creynders/backbone.geppetto/blob/injector/backbone.geppetto.js#L139

The optional wiring parameter passed to resolve however overwrites the wiring value of the dependent.
PR coming your way.