![Introducing Enhanced Alert Actions and Triage Functionality](https://cdn.sanity.io/images/cgdhsj6q/production/fe71306d515f85de6139b46745ea7180362324f0-2530x946.png?w=800&fit=max&auto=format)
Product
Introducing Enhanced Alert Actions and Triage Functionality
Socket now supports four distinct alert actions instead of the previous two, and alert triaging allows users to override the actions taken for all individual alerts.
@owja/ioc
Advanced tools
Readme
This library implements dependency injection for javascript. It is currently work in progress and in unstable beta phase but the API should not change anymore before 1.0.0 stable release will arrive.
The container is the place where all dependencies get bound to. We can have multiple containers in our project in parallel.
import {Container} from "@owja/ioc";
const container = new Container();
This is the default way to bind a dependency. The class will get instantiated when the dependency gets resolved.
container.bind<ServiceInterface>(symbol).to(Service);
This will create only one instance of Service
container.bind<ServiceInterface>(symbol).to(Service).inSingletonScope();
Factories are functions which will get called when the dependency gets resolved
container.bind<ServiceInterface>(symbol).toFactory(() => new Service());
container.bind<string>(symbol).toFactory(() => "just a string");
A factory can configured for singleton scope too. This way will only executed once.
container.bind<ServiceInterface>(symbol).toFactory(() => new Service()).inSingletonScope();
This is always like singleton scope, but it should be avoid to instantiate dependencies here. If they are circular dependencies, they will fail.
container.bind<ServiceInterface>(symbol).toValue(new Service());
container.bind<string>(symbol).toValue("just a string");
container.bind<() => string>(symbol).toValue(() => "i am a function");
This is the way how we can rebind a dependency while unit tests. We should not need to rebind in production code.
container.rebind<ServiceMock>(symbol).toValue(new ServiceMock());
Normally this function is not used in production code. This will remove the dependency from the container.
container.remove(symbol);
Getting dependencies without inject
decorators are only meant for unit tests. This is also
the internal way the inject
decorator gets the dependency it has to resolve.
container.get<Interface>(symbol);
This creates a snapshot of the bound dependencies. After this we can rebind dependencies and can restore it back to its old state after we made some unit tests.
container.snapshot();
container.restore();
inject
DecoratorWe have to create a inject
decorator for each container.
import {createDecorator} from "@owja/ioc";
export const inject = createDecorator(container);
This decorator is needed to resolve our dependencies.
class Example {
@inject(symbol)
readonly service!: Interface;
}
symbol
Symbols are used to identify our dependencies. A good practice is to keep them in one place.
export const TYPE = {
"Service" = Symbol("Service"),
// [...]
}
Symbols can be defined with Symbol.for()
too. This way they are not unique.
Remember Symbol('foo') === Symbol('foo')
is false
but
Symbol.for('foo') === Symbol.for('foo')
is true
export const TYPE = {
"Service" = Symbol.for("Service"),
// [...]
}
Since 1.0.0-beta.3 we use the symbol itself for indexing the dependencies. Prior to this version we indexed the dependencies by the string of the symbol.
npm install --save-dev @owja/ioc
Now we create the folder services and add the new file services/types.ts:
export const TYPE = {
"MyService" = Symbol("MyService"),
"MyOtherService" = Symbol("MyOtherService"),
};
Next we need a container to bind our dependencies to. Let's create the file services/container.ts
import {Container, createDecorator} from "@owja/ioc";
import {TYPE} from "./types";
import {IMyService, MyService} from "./service/my-service";
import {IMyOtherService, MyOtherService} from "./service/my-other-service";
const container = new Container();
const inject = createDecorator(container);
container.bind<IMyService>(TYPE.MyService).to(MyService);
container.bind<IMyOtherService>(TYPE.MyOtherService).to(MyOtherService);
export {container, TYPE, inject};
Lets create a example.ts file in our source root:
import {container, TYPE, inject} from "./services/container";
import {IMyService} from "./service/my-service";
import {IMyOtherService} from "./service/my-other-service";
class Example {
@inject(TYPE.MyService)
readonly myService!: IMyService;
@inject(TYPE.MyOtherSerice)
readonly myOtherService!: IMyOtherService;
}
const example = new Example();
console.log(example.myService);
console.log(example.myOtherSerice);
If we run this example we should see the content of our example services.
The dependencies (services) will injected on the first call. This means if you rebind the service after
accessing the properties of the Example class, it will not resolve the new service. If you want a new
service each time you call example.myService
you have to add the NOCACHE
tag:
import {container, TYPE, inject} from "./services/container";
import {NOCACHE} from "@owja/ioc";
// [...]
class Example {
@inject(TYPE.MyService, NOCACHE)
readonly myService!: IMyService;
@inject(TYPE.MyOtherSerice, NOCACHE)
readonly myOtherService!: IMyOtherService;
}
// [...]
We can snapshot and restore a container for unit testing. We are able to make multiple snapshots in a row too.
import {container, TYPE} from "./services/container";
beforeEach(() => {
container.snapshot();
});
afterEach(() => {
container.restore();
}
test("can do something", () => {
container.rebind<MyServiceMock>(TYPE.MySerice).to(MyServiceMock);
const mock = container.get<MyServiceMock>(TYPE.MySerice);
});
We are working on the first stable release. Current state of development can be seen in our Github Project for the first release.
This library is highly inspired by InversifyJS but has other goals:
License under Creative Commons Attribution 4.0 International
Copyright © 2019 Hauke Broer
FAQs
dependency injection for javascript
The npm package @owja/ioc receives a total of 1,275 weekly downloads. As such, @owja/ioc popularity was classified as popular.
We found that @owja/ioc 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.
Product
Socket now supports four distinct alert actions instead of the previous two, and alert triaging allows users to override the actions taken for all individual alerts.
Security News
Polyfill.io has been serving malware for months via its CDN, after the project's open source maintainer sold the service to a company based in China.
Security News
OpenSSF is warning open source maintainers to stay vigilant against reputation farming on GitHub, where users artificially inflate their status by manipulating interactions on closed issues and PRs.