console.log(diContext.baseUrl);//This will printout 'localhost'
Adding hints to the context
The real value of the dependency injection is to get it to create complex objects for you.
This is the case for hints, (functions or class definitions)
Parameterless hints
When you need to add hints, which class constructor or function are parameterless, you can do this by passing the class or the function reference directly.
myAmazingObject: MyAmazingClass,// this is class hint
});
console.log(
diContext.myAmazingObject.saySomething()
);//This will print 'something'
Internal dependencies
Now that we have seen the simplest case of parameterless hints, let's see what would happen if we needed to specify an internal dependency.
Let's also show something closer to a real world case, let's imagine that the strings to be used for MyAmazingClass could be configured from the outside as you might need to if your applications supports many locales.
Because functions and class are always assumed to be hints, you will find that it might now work as you expect if you need to have a dependency to be resolved to a function or a class...
The bean definition in the example above 'sayHello' is considered to be a hint (is a function), so if you access it through the context, the actual result would be the string 'hello'
console.log(diContext.sayHello);//This will printout 'hello'
console.log(diContext.sayHello());//This will throw an error
If you wanted the function to be used as a value, and not as a hint, you will have to wrap it into an additional function.
This will trick the framework in resolving it to your original function, for instance to receive as a bean the function sayHello, instead of its returning value:
stockEndpoint: A hint for the class Endpoint. Note that the constructor receives a parameter named 'baseUrl', this matches the aux bean definition, which means that it will be injected into the stockEndpoint bean.
stockService. A hint for the class StockService, the bean created in this context will receive injected through the constructor the stockEndpoint.
Dynamic context
A side effect of working with plain objects to store the context, is that as with as any other normal object, you can use functions to generate the context, or that you can change the context after it has been created.
You will see in the next section how this combined with the other features from dependency injection will let you for example write simpler integration tests.
We think that having a dynamic context is key to fully take advantage of the dependency injection
As of v1.0, we don't have any out of the box mechanism to help you create dynamic context, but we are hoping to change this in the near future.