Gathering detailed insights and metrics for @ablestack/inversify-react
Gathering detailed insights and metrics for @ablestack/inversify-react
Components and decorators to connect react with inversify.
npm install @ablestack/inversify-react
Typescript
Module System
Node Version
NPM Version
TypeScript (96.88%)
JavaScript (3.12%)
Verify real, reachable, and deliverable emails with instant MX records, SMTP checks, and disposable email detection.
Total Downloads
526
Last Day
2
Last Week
2
Last Month
5
Last Year
97
Apache-2.0 License
58 Commits
1 Watchers
2 Branches
1 Contributors
Updated on Jul 01, 2021
Minified
Minified + Gzipped
Latest Version
1.0.0
Package Id
@ablestack/inversify-react@1.0.0
Unpacked Size
67.36 kB
Size
17.25 kB
File Count
14
NPM Version
7.7.6
Node Version
15.14.0
Cumulative downloads
Total Downloads
Last Day
0%
2
Compared to previous day
Last Week
0%
2
Compared to previous week
Last Month
-70.6%
5
Compared to previous month
Last Year
-24.2%
97
Compared to previous year
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
Hooks and decorators for InversifyJS + React.
Table of Contents
TL;DR:
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 is pretty similar to React Context.
Wrap React component tree with Provider
and Container
from inversify-react
– just like React Context.Provider
1import { Provider } from 'inversify-react'; 2... 3 4<Provider container={myContainer}> 5 ... 6</Provider>
Use dependencies from that container in child components
1import { resolve, useInjection } from 'inversify-react'; 2... 3 4// In functional component – via hooks 5const ChildComponent: React.FC = () => { 6 const foo = useInjection(Foo); 7 ... 8}; 9 10// or in class component – via decorated fields 11class ChildComponent extends React.Component { 12 @resolve 13 private readonly foo: Foo; 14 ... 15}
1<Provider container={myContainer}>...</Provider>
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.1import * as React from "react"; 2import { Container } from "inversify"; 3import { Provider } from "inversify-react"; 4 5// in functional component 6const AppOrModuleRoot: React.FC = () => { 7 return ( 8 <Provider 9 container={() => { 10 const container = new Container(); 11 container.bind(Foo).toSelf(); 12 container.bind(Bar).toSelf(); 13 return container; 14 }} 15 > 16 {/*...children...*/} 17 </Provider> 18 ); 19}; 20 21// or class component 22class AppOrModuleRoot extends React.Component { 23 // you can create and store container instance explicitly, 24 // or use factory function like in functional component example above 25 private readonly container = new Container(); 26 27 constructor(props: {}, context: {}) { 28 super(props, context); 29 30 const { container } = this; 31 container.bind(Foo).toSelf(); 32 container.bind(Bar).toSelf(); 33 } 34 35 render() { 36 return <Provider container={this.container}>{/*...children...*/}</Provider>; 37 } 38}
1const foo = useInjection(Foo);
1// e.g. Foo and Bar are not bound 2const foo = useOptionalInjection(Foo); // will return undefined 3// or 4const bar = useOptionalInjection(Bar, () => "defaultBar"); // will return 'defaultBar'
That function conveniently receives container as argument, so you could instantiate your default using container (e.g. if it has dependencies)1const foo = useOptionalInjection(Foo, () => myDefault); 2// foo === myDefault 3// ^ Foo | typeof myDefault
1const foo = useOptionalInjection(Foo, (container) => container.resolve(X));
1const container = useContainer(); 2// or 3const foo = useContainer((container) => container.resolve(Foo));
1const bars = useAllInjections(Bar);
For more examples, please refer to tests: test/hooks.tsx
1@resolve 2foo: Foo; 3 4// or strict and semantic, see tips below 5@resolve 6private readonly foo!: Foo;
reflect-metadata
and emitDecoratorMetadata
1// or pass service identifier explicitly 2// e.g. if you deal with interfaces and/or don't want to use field type (via reflect-metadata) 3@resolve(IFooServiceId) 4private readonly foo!: IFoo;
1@resolve.optional 2private readonly foo?: Foo;
undefined
if service cannot be obtainedreflect-metadata
and emitDecoratorMetadata
@resolve.optional(serviceId, defaultValue?)
defaultValue
if service cannot be obtained1class ChildComponent extends React.Component { 2 @resolve 3 private readonly foo!: Foo; 4 5 @resolve(Bar) 6 private readonly bar!: Bar; 7 8 @resolve.optional(Baz) 9 private readonly opt?: Baz; 10 11 ... 12} 13 14// you can also use dependency in constructor, 15// just don't forget to call super with context 16// @see https://github.com/facebook/react/issues/13944 17constructor(props: {}, context: {}) { 18 super(props, context); 19 console.log(this.foo.name); 20}
[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.
1export interface IFoo { 2 // ... 3} 4export namespace IFoo { 5 export const $: interfaces.ServiceIdentifier<IFoo> = Symbol("IFoo"); 6}
1container.bind(IFoo.$).to(...); 2// ^ no need to specify generic type, 3// type gets inferred from explicit service identifier
1// in constructor injections (not in React Components, but in services/stores/etc) 2constructor(@inject(IFoo.$) foo: IFoo) 3 4// in React Class component 5@resolve(IFoo.$) 6private readonly foo!: IFoo; // less imports and less chance of mix-up 7 8// in functional component 9const foo = useInjection(IFoo.$); // inferred as IFoo 10
No vulnerabilities found.
No security vulnerabilities found.