inversify-react
Hooks and decorators for InversifyJS + React.
Table of Contents
Motivation
TL;DR:
- InversifyJS, as IoC container, is great for automatic DI
- use it also in React
Installation
npm install --save inversify-react
yarn add inversify-react
...on top of your project with other modules already installed and configured
react
inversify
reflect-metadata
Keep in mind that Inversify uses decorators, which requires some setup for your build process.
Read more about decorators:
inversify-react
also uses decorators, but only when used in Class Components.
Usage overview
Usage is pretty similar to React Context.
-
Wrap React component tree with Provider
and Container
from inversify-react
– just like React Context.Provider
import { Provider } from 'inversify-react';
...
<Provider container={myContainer}>
...
</Provider>
-
Use dependencies from that container in child components
import { resolve, useInjection } from 'inversify-react';
...
const ChildComponent: React.FC = () => {
const foo = useInjection(Foo);
...
};
class ChildComponent extends React.Component {
@resolve
private readonly foo: Foo;
...
}
Provider
<Provider container={myContainer}>
...
</Provider>
- provides contextual IoC container for children, similar to React Context.Provider
- can automatically establish hierarchy of containers in React tree when you use multiple Providers (e.g. in a big modular app)
- props:
container
- container instance or container factory functionstandalone
- (optional prop, false
by default) whether to skip hierarchy of containers. Could be useful if you already control container hierarchy and would like to ignore React-tree-based hierarchy.
import * as React from 'react';
import { Container } from 'inversify';
import { Provider } from 'inversify-react';
const AppOrModuleRoot: React.FC = () => {
return (
<Provider container={() => {
const container = new Container();
container.bind(Foo).toSelf();
container.bind(Bar).toSelf();
return container;
}}>
{/*...children...*/}
</Provider>
);
};
class AppOrModuleRoot extends React.Component {
private readonly container = new Container();
constructor(props: {}, context: {}) {
super(props, context);
const { container } = this;
container.bind(Foo).toSelf();
container.bind(Bar).toSelf();
}
render() {
return (
<Provider container={this.container}>
{/*...children...*/}
</Provider>
);
}
}
React hooks
useInjection
const foo = useInjection(Foo);
useOptionalInjection
const foo = useOptionalInjection(Foo);
const bar = useOptionalInjection(Bar, () => 'defaultBar');
- resolves optional dependency
- default value can be defined via lazy resolving function (2nd argument)
const foo = useOptionalInjection(Foo, () => myDefault);
That function conveniently receives container as argument, so you could instantiate your default using container (e.g. if it has dependencies)
const foo = useOptionalInjection(Foo, container => container.resolve(X));
useContainer
const container = useContainer();
const foo = useContainer(container => container.resolve(Foo));
- low-level hook, resolves container itself
- has overload with callback to immediately resolve value from container, so could be used for more exotic API, e.g. named or tagged bindings
useAllInjections
const bars = useAllInjections(Bar);
For more examples, please refer to tests: test/hooks.tsx
React component decorators (for classes)
@resolve
@resolve
foo: Foo;
@resolve
private readonly foo!: Foo;
- resolves service from container
- requires
reflect-metadata
and emitDecoratorMetadata
@resolve(IFooServiceId)
private readonly foo!: IFoo;
@resolve.optional
@resolve.optional
private readonly foo?: Foo;
- tries to resolve service from container, but returns
undefined
if service cannot be obtained - requires
reflect-metadata
and emitDecoratorMetadata
@resolve.optional(serviceId, defaultValue?)
- obtains service from container passed down in the React tree, returns
defaultValue
if service cannot be obtained
class ChildComponent extends React.Component {
@resolve
private readonly foo!: Foo;
@resolve(Bar)
private readonly bar!: Bar;
@resolve.optional(Baz)
private readonly opt?: Baz;
...
}
constructor(props: {}, context: {}) {
super(props, context);
console.log(this.foo.name);
}
@resolve.all
@resolve.all('Foo')
private readonly foo!: Foo[];
- tries to resolve all services from container, fails if no services are bound to given service identifier
- requires
reflect-metadata
and emitDecoratorMetadata
, but cannot be used without explicitly specifying service identifier
@resolve.all(serviceId)
- obtains services from container passed down in the React tree
class ChildComponent extends React.Component {
@resolve.all(Baz)
private readonly all!: Baz[];
...
}
@resolve.optional.all
@resolve.optional.all('Foo')
private readonly foo!: Foo[];
- tries to resolve all services from container, returns empty array if none are registered
- requires
reflect-metadata
and emitDecoratorMetadata
, but cannot be used without explicitly specifying service identifier
@resolve.optional.all(serviceId)
- obtains services from container passed down in the React tree
class ChildComponent extends React.Component {
@resolve.optional.all(Baz)
private readonly allorempty!: Baz[];
...
}
Notes, tips
-
[TypeScript tip] private readonly
for @resolve
-ed fields is not required, but technically it's more accurate, gives better semantics and all.
-
[TypeScript tip] !
for @resolve
-ed fields is needed for strictPropertyInitialization / strict flags (which are highly recommended).
-
[InversifyJS tip] If you're binding against interface, then it might be more comfortable to collocate service identifier and type. With typed service identifier you get better type inference and less imports. Way better DX compared to using strings as identifiers.
export interface IFoo {
}
export namespace IFoo {
export const $: interfaces.ServiceIdentifier<IFoo> = Symbol('IFoo');
}
container.bind(IFoo.$).to(...);
constructor(@inject(IFoo.$) foo: IFoo)
@resolve(IFoo.$)
private readonly foo!: IFoo;
const foo = useInjection(IFoo.$);