Lazy Loading (toAsyncValue) support

[parisholley]

Allow for users to opt-in to lazy loaded dependencies by using an asynchronous API.

Description

New container methods for pulling objects out of the container in an asynchronous fashion while respecting container semantics and error if trying to mix synchronous/asynchronous dependencies.

Implementation

container.bind<Type>('name').toAsyncValue(async () => {
  return await myAsyncFunction();
});
container.bind<string>('resolve').toAsyncValue(async () => Promise.resolve('foobar'));

const value = await container.getAsync<Type>('name'); // result of myAsyncFunction
const value = await container.get<Type>('name'); // throws an exception
const value = await container.getAsync<string>('resolve'); // foobar

For anyone wanting to play around with this, you can use the NPM release:

@parisholley/inversify-async:1.0.20

Related Issue

#418
#475
#887
#404

Motivation and Context

Use Case 1: Unit/System Testing
While you technically could create separate containers (with a parent container for common objects) for a unit test environment and system test (database, etc), it adds more code complexity and also requires each system integration be live and working in order to bootstrap the container (this matters, because for instance in the IDE, if I want to run a single test, with a single I/O dependency, I don't have to initiate every connection).

Use Case 2: Common Container Use
Let's say you have a "service" code base that is re-used between a web application, command line interface and batch processing. In the case of the CLI, you have different commands that serve different purpose, eg:

• Clone production data
• Invoke third party service

By making I/O dependencies lazy loaded (async), our CLI can wait until runtime to connect to the system that it needs for the task (otherwise, same problem as above, you are forced to connect-to, and have access-to systems that are unrelated to the command at hand).

How Has This Been Tested?

Full suite of tests have been implemented to.

Types of changes

• Updated docs / Refactor code / Added a tests case (non-breaking change)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the changelog.

[parisholley]

@remojansen @dcavanagh @Jameskmonger thoughts on this?

[Jameskmonger]

Use arrow functions rather than function

[parisholley]

reasoning? the prior functions in this file follow this format

[seizir]

Would it be possible to add the context to the async function like in toDynamicValue, toFactory, and toProvider? That would make it a lot more useful.

container.bind<string>('text').toAsyncValue(async (context) => {
    const first = await context.container.getAsync<string>('firsthalf');
    const second = context.container.get<string>('secondhalf');
    return first + second;
}

[parisholley]

@seizir i wanted to, but it makes the implementation very complex as the async functions can be evaluated at any time and context can change. if you need access to the container, i recommend accessing it via closure instead:

const container = ....

container.bind().toAsyncValue(async () => {
const first = container.get();
})

[seizir]

@parisholley That solution should work in most cases but not if modules are used because there is no way to access the container from there except via the context.

[seizir]

toAsyncValue ignores defaultScope

const container = new Container({defaultScope: 'Singleton'});
container.bind('a').toAsyncValue( async () => Math.random());

async function f() {
    console.log(await container.getAsync('a')); // 0.5358571181438059
    console.log(await container.getAsync('a')); // 0.4785245037836447
}

f();

const container = new Container();
container.bind('a').toAsyncValue( async () => Math.random()).inSingletonScope();

async function f() {
    console.log(await container.getAsync('a')); // 0.8363558846768307
    console.log(await container.getAsync('a')); // 0.8363558846768307
}

f();

[parisholley]

@seizir i can't reproduce this in a mocha test, what version of my NPM module are you using?

[seizir]

@parisholley I am using 1.0.12
I created a repository demonstrating the bug https://github.com/seizir/inversify-async-bug

[parisholley]

@seizir fixed in 1.0.13

[parisholley]

closing and continuing with #1132