@ablestack/inversify-react 中文文档教程
Fork Note
这是出色的 inversify-react 库 的分支副本,仅供 ablestack 项目使用。 分叉这个库的主要驱动力是变更控制。 该库还不够成熟,无法在没有额外的抽象层和代码审查的情况下直接包含在生产项目中(此分支旨在为 ablestack 项目提供)
以下所有文档均来自原始 反向反应项目
inversify-react
InversifyJS + 反应。
目录
- Motivation
- Installation
- Usage overview
- Provider
- React hooks
- useInjection
- useOptionalInjection
- useContainer
- useAllInjections
- React component decorators (for classes)
- @resolve
- @resolve.optional
- Notes, tips
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
...在您的项目之上,已经安装和配置了其他模块
react
inversify
reflect-metadata
请记住,Inversify 使用装饰器,这需要为您的构建过程进行一些设置。
阅读有关装饰器的更多信息:
- https://github.com/inversify/InversifyJS#installation
- https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy
- https://www.typescriptlang.org/docs/handbook/decorators.html
inversify-react
也使用装饰器,但仅在类组件中使用时。
Usage overview
用法与 React Context 非常相似。
- Wrap React component tree with
Provider
andContainer
frominversify-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';
...
// In functional component – via hooks
const ChildComponent: React.FC = () => {
const foo = useInjection(Foo);
...
};
// or in class component – via decorated fields
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";
// in functional component
const AppOrModuleRoot: React.FC = () => {
return (
<Provider
container={() => {
const container = new Container();
container.bind(Foo).toSelf();
container.bind(Bar).toSelf();
return container;
}}
>
{/*...children...*/}
</Provider>
);
};
// or class component
class AppOrModuleRoot extends React.Component {
// you can create and store container instance explicitly,
// or use factory function like in functional component example above
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);
- very similar to React.useContext hook, resolves dependency by id
useOptionalInjection
// e.g. Foo and Bar are not bound
const foo = useOptionalInjection(Foo); // will return undefined
// or
const bar = useOptionalInjection(Bar, () => "defaultBar"); // will return 'defaultBar'
- resolves optional dependency
- default value can be defined via lazy resolving function (2nd argument)
const foo = useOptionalInjection(Foo, () => myDefault);
// foo === myDefault
// ^ Foo | typeof myDefault
该函数方便地接收容器作为参数,因此您可以使用容器实例化您的默认(例如,如果它具有依赖项)
const foo = useOptionalInjection(Foo, (container) => container.resolve(X));
useContainer
const container = useContainer();
// or
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);
- @see multi-inject
有关更多示例,请参阅测试:test/hooks.tsx
React component decorators (for classes)
@resolve
@resolve
foo: Foo;
// or strict and semantic, see tips below
@resolve
private readonly foo!: Foo;
- resolves service from container
- requires
reflect-metadata
andemitDecoratorMetadata
// or pass service identifier explicitly
// e.g. if you deal with interfaces and/or don't want to use field type (via reflect-metadata)
@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
andemitDecoratorMetadata
@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;
...
}
// you can also use dependency in constructor,
// just don't forget to call super with context
// @see https://github.com/facebook/react/issues/13944
constructor(props: {}, context: {}) {
super(props, context);
console.log(this.foo.name);
}
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(...);
// ^ no need to specify generic type,
// type gets inferred from explicit service identifier
// in constructor injections (not in React Components, but in services/stores/etc)
constructor(@inject(IFoo.$) foo: IFoo)
// in React Class component
@resolve(IFoo.$)
private readonly foo!: IFoo; // less imports and less chance of mix-up
// in functional component
const foo = useInjection(IFoo.$); // inferred as IFoo
Fork Note
This is a forked copy of the excellent inversify-react library, intended for ablestack project consumption only. The primary driver for forking this library is change-control. The library is not well-established enough to include in production projects directly without an additional layer of abstraction and code-review (which this fork is intended to provide for ablestack projects)
All the following documentation is from the original inversify-react project
inversify-react
Hooks and decorators for InversifyJS + React.
Table of Contents
- Motivation
- Installation
- Usage overview
- Provider
- React hooks
- useInjection
- useOptionalInjection
- useContainer
- useAllInjections
- React component decorators (for classes)
- @resolve
- @resolve.optional
- Notes, tips
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:
- https://github.com/inversify/InversifyJS#installation
- https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy
- https://www.typescriptlang.org/docs/handbook/decorators.html
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
andContainer
frominversify-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';
...
// In functional component – via hooks
const ChildComponent: React.FC = () => {
const foo = useInjection(Foo);
...
};
// or in class component – via decorated fields
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";
// in functional component
const AppOrModuleRoot: React.FC = () => {
return (
<Provider
container={() => {
const container = new Container();
container.bind(Foo).toSelf();
container.bind(Bar).toSelf();
return container;
}}
>
{/*...children...*/}
</Provider>
);
};
// or class component
class AppOrModuleRoot extends React.Component {
// you can create and store container instance explicitly,
// or use factory function like in functional component example above
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);
- very similar to React.useContext hook, resolves dependency by id
useOptionalInjection
// e.g. Foo and Bar are not bound
const foo = useOptionalInjection(Foo); // will return undefined
// or
const bar = useOptionalInjection(Bar, () => "defaultBar"); // will return 'defaultBar'
- resolves optional dependency
- default value can be defined via lazy resolving function (2nd argument)
const foo = useOptionalInjection(Foo, () => myDefault);
// foo === myDefault
// ^ Foo | typeof 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();
// or
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);
- @see multi-inject
For more examples, please refer to tests: test/hooks.tsx
React component decorators (for classes)
@resolve
@resolve
foo: Foo;
// or strict and semantic, see tips below
@resolve
private readonly foo!: Foo;
- resolves service from container
- requires
reflect-metadata
andemitDecoratorMetadata
// or pass service identifier explicitly
// e.g. if you deal with interfaces and/or don't want to use field type (via reflect-metadata)
@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
andemitDecoratorMetadata
@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;
...
}
// you can also use dependency in constructor,
// just don't forget to call super with context
// @see https://github.com/facebook/react/issues/13944
constructor(props: {}, context: {}) {
super(props, context);
console.log(this.foo.name);
}
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(...);
// ^ no need to specify generic type,
// type gets inferred from explicit service identifier
// in constructor injections (not in React Components, but in services/stores/etc)
constructor(@inject(IFoo.$) foo: IFoo)
// in React Class component
@resolve(IFoo.$)
private readonly foo!: IFoo; // less imports and less chance of mix-up
// in functional component
const foo = useInjection(IFoo.$); // inferred as IFoo