npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@ablestack/inversify-react

v1.0.0

Published

A copy of Kukkimonsuta/inversify-react - Components and decorators to connect react with inversify - only intended for ablestack consumers

Downloads

4

Readme

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

npm version

npm peer dependency version npm peer dependency version


Hooks and decorators for InversifyJS + React.


Table of Contents

Motivation

TL;DR:

  1. InversifyJS, as IoC container, is great for automatic DI
  2. 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.

  1. 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>
  2. 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 function
    • standalone - (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);

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);

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 and emitDecoratorMetadata
// 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 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;

    ...
}

// 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

  1. [TypeScript tip] private readonly for @resolve-ed fields is not required, but technically it's more accurate, gives better semantics and all.

  2. [TypeScript tip] ! for @resolve-ed fields is needed for strictPropertyInitialization / strict flags (which are highly recommended).

  3. [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