dependency-injection
Advanced tools
Dependency injection with configuration and autowire for node js and browser
Dependency injection with configuration and autowire for node js and browser (for example in combination with simq).
Imagine, that you have got some classes which are used very often. You have got two options: add instance of these classes to window object or to any other object, or create new instance every time when you want to use them.
The problem is that first solution add some "mess" to the window object and the other one is even more problematic. What if you will want to change for example constructor of this class (it's arguments) or call some methods right after class is instanced? Than you will have to change these setups at every place.
But with this package, you can configure your classes at one place and then let's just "ask" for them. (not service locator).
This package is inspired by dependency injection in Nette framework.
$ npm install dependency-injection
You can see full documentation of easy-configuration here. This package is used for configuration your services (classes).
{
"services": {
"application": {
"service": "path/to/my/application/module",
"arguments": ["./www", "someOtherVariable"],
"setup": {
"setApplicationName": ["nameOfApplication"],
"setSomethingOther": ["someUselessVariable", "andAnotherOne"]
}
}
}
}
There we set some application service with some arguments which will be given to constructor and some setup. Every time you will need this service, it will have got these arguments and all setup function will be called.
Section service is path for module require (common js).
DI automatically look into values from setup in your module (service). If it is function, then it will be called, otherwise argument will be passed into this object property.
var DIConfigurator = require('dependency-injection/DIConfigurator');
var configurator = new DIConfigurator('/path/to/your/configuration/file.json');
var di = configurator.create();
di.basePath = __dirname;
This will create new instance of DI class which holding all your services.
You have to also set the basePath property. DI will prepend this basePath to all services' paths from your configuration. So it should be path to root directory of your application.
In example below, you can see how to get your services.
di.get('application');
di.create('application');
di.getFactory('application');
DI can be automatically exposed into window object (when on browser) or into global object (in node). Default name for
this object is di.
{
"setup": {
"expose": true
}
}
Custom name:
{
"setup": {
"expose": "secondDI"
}
}
Some services may be "singleton" type (not really singleton but with one instance in whole application), which application service is clearly is.
This method will create one instance of service and store it. Every other time, this instance will be returned.
Same as get method, but this accepts path to node module (like in your service configuration)
Method create will just create new instance of service and will not store it.
getFactory is almost the same like create method, but will return anonymous function, so if you then want to use it, you have to call it.
var application = di.getFactory('application');
application = application(); // just call it
When you want for example use jQuery as service, you will not want to automatically call something like new jquery.
So you can tell DI, that this service will not be instantiate.
{
"services": {
"jquery": {
"service": "jquery"
"instantiate": false
}
}
}
When you are using configuration with json files, you can set some services to be started automatically after calling
the create method.
{
"services": {
"setup": {
"service": "./path/to/setup",
"run": true
}
}
}
Accessing some DI object is not so pretty like we want, so there is some nice way how to avoid it. You can let DI to "inject" all your services to other. For example if your application service needs translator service, just let DI to give it to application.
All you need to do is add parameter "translator" to constructor of your application service. This name must be same like name of service in your configuration. DI then automatically give it translator service.
The same thing is also for methods. You don't have to configure them, just set name of needed service in method's arguments and DI will give you these services.
This is quite similar to dependency injection in angular.
Now in most cases you just have to use get method just once for create instance of your base application service
and other services will be automatically injected.
Please, try to avoid circular dependencies (service A depends on service B and service B depends on service A).
In your configuration, you can use three dots as replacement for services.
Services:
var serviceA = function(serviceB, serviceC) { ... };
var serviceB = function(serviceC, namespace, item) { ... };
var serviceC = function(namespace, item, serviceD) { ... };
var serviceD = function() { ... };
Configuration:
{
"services": {
"serviceA": {
"service": "path/to/service/A",
"instantiate": false
},
"serviceB": {
"service": "path/to/service/B",
"arguments": ["...", "some namespace", "some item"],
"instantiate": false
},
"serviceC": {
"service": "path/to/service/C",
"arguments": ["some namespace", "some item"],
"instantiate": false
},
"serviceD": {
"service": "path/to/service/D",
"instantiate": false
}
}
}
or more expanded:
{
"services": {
"serviceA": {
"service": "path/to/service/A",
"arguments": ["..."],
"instantiate": false
},
"serviceB": {
"service": "path/to/service/B",
"arguments": ["...", "some namespace", "some item"],
"instantiate": false
},
"serviceC": {
"service": "path/to/service/C",
"arguments": ["some namespace", "some item", "..."],
"instantiate": false
},
"serviceD": {
"service": "path/to/service/D",
"arguments": ["..."],
"instantiate": false
}
}
}
Only problem is with minified javascript files which changes variable names. Solution for this is write some kind of hint for DI container.
var someFunction = function(otherNameForApplicationService) {
{'@di:inject': ['@application']}; // services' names are prepended with '@'
otherNameForApplicationService.run(); // this will call method run on service application
};
or you can also include services by their full paths:
var someFunction = function(otherNameForApplicationService) {
{'@di:inject': ['$path/to/application/service']}; // services' paths are prepended with '$'
otherNameForApplicationService.run();
};
or if you need factory:
var someFunction = function(otherNameForApplicationService) {
{'@di:inject': ['factory:$path/to/application/service']}; // can also be name of service: "factory:@application"
otherNameForApplicationService.run();
};
If you want to disable autowiring for some service, you can set "autowired" option to false in your config (like instantiate).
When you will try to autowire this service, DI will throw an error.
{
"services": {
"setup": {
"someName": "./path/to/this/service",
"autowired": false
}
}
}
You can also let DI to autowire factories. For example if you want to get factory for translator, you will add "Factory" to the end of translator.
MyClass.prototype.setTranslator = function(translatorFactory) {
var translator = translatorFactory(); // now do something with translator
};
When you have got for example foreign library registered as service in this DI and want to autowire some other service into it, you have to use their names of methods arguments.
Another possibility is to set these services in your config.
{
"services": {
"foreignLibrary": {
"service": "path/to/service",
"arguments": [
"@translator"
]
}
}
}
or with full module path:
{
"services": {
"foreignLibrary": {
"service": "path/to/service",
"arguments": [
"$path/to/translator/module"
]
}
}
}
Now this foreignLibrary will gets your translator service in constructor.
Autowiring DI container is also possible. Only thing you need to do, is set argument with name "di" into your method or constructor. This also means that you can not register new service with name "di".
di.get('di');
Maybe it will be better for someone to use this DI without configuration, so here is example of application, translator and jquery definition.
var DI = require('dependency-injection');
var di = new DI;
di.addService('application', require('./path/to/my/application/module'), ['./www', 'someOtherVariable'])
.addSetup('setApplicationName', ['nameOfApplication'])
.addSetup('setSomethingOther', ['someUselessVariable', 'andAnotherOne']);
di.addService('translator', require('./path/to/translator'))
.addSetup('setLanguage', ['en']);
di.addService('jquery', 'jquery')
.setInstantiate(false);
di.addService('private', 'my/private/service')
.setAutowired(false);
Instead of path to service (second parameter in addService method) you can also use string with path, but this path will be then relative to class of DI!
If you have got some other object which you want to use with other services, but can not use configuration or DI for this,
you can use createInstance method and DI will create new instance of your object with dependencies defined in constructor.
var SuperClass = require('./mySuperClass');
var super = di.createInstance(SuperClass, ['and some argument']);
For simple injecting services into your functions, you can use method inject.
di.inject(function(application) {
application.doSomeMagic();
});
$ npm test
2.0.1
2.0.0
inject methods (BC break!)getByPath and getFactoryByPath1.8.0
1.7.3
1.7.2
1.7.1
1.7.0
injectMethods to servicesDI.autowireArguments moved to Helpers.autowireArguments1.6.6 - 1.6.7
1.6.2 - 1.6.5
1.6.1
1.6.0
get method, getByName is now deprecatedinject method1.5.2
1.4.1
1.4.0
1.3.2 - 1.3.3
1.3.1
1.3.0
1.2.3
1.2.2
1.2.1
1.2.0
1.1.1
1.1.0
1.0.1
1.0.0
FAQs
[ABANDONED] Dependency injection with configuration and autowire for node js and browser
The npm package dependency-injection receives a total of 2 weekly downloads. As such, dependency-injection popularity was classified as not popular.
We found that dependency-injection demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
PyPI confirms no security flaws were exploited in the Ultralytics supply chain attack and highlights improvements for safer package publishing.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.