livshitz / di.libx.js

💉 di.libx.js - Lightweight & non intrusive Dependency Injection module that supports async/deferred resolution and uglified support

Hi there 👋

di.libx.js's Issues

Syntax highlighting in Readme

Hey, I saw your project on Reddit and was interested in checking it out. I notice your code examples in the Readme don't have colours like you'd find in an IDE. If you want I can make a small contribution to the project by adding syntax highlighting to the code in the Readme so it can be read and understood easier.

Add support for automatic module constructor dependency resolution

So you could pass a class and DI will try to find registered module and initiate it for you.

Add support for lifetime with sub-container linkage

A DI container instance should be able to get a "parent" container, in which it could search for registered module if not found locally.
Container constructor should be able to get optional parent instance.
The instance reference should be weak, so once the scope/context of the sub container died, GC would clear up the reference, hence will be container's (and its registered modules) lifetime.

Add support in `getParamNames` for different function declaration formats and support class's constructor

So we could get properly the parameters for those variations:

class MyClass {
	constructor(paramA, paramB,  paramC) {}
}
const funcArrow = (paramA, paramB,  paramC) => {};
const funcArrowNoParentheses = paramA => {};
function funcExpression(paramA, paramB,  paramC){};
function functionDouble(paramA, paramB,  paramC){};
const funcSelfExec = ((paramA, paramB, paramC) => {});
function* yieldAndReturn(paramA, paramB, paramC) {}

Convert `var` to `const` or `let`

Especially in:
DependencyInjector.ts

Add example for real-world how far flung components require distant components

Original question:

How do far flung components get to use di.require(..) ? All the examples are di.register(..) immediately followed by di.require(..)

Answer:

Generally, you're free to decide how you manage the 'master' container singleton, but best practice would be to define myContainer.js, initiate DependencyInjector in it (as show in the examples) and export the container instance.
Anywhere else in the app you should import myContainer.js and require the other dependencies there.

So it'd be best to add such example in code/docs.

Add typed support for Symbol as a key and tests

To allow multiple modules with same name. With Symbol each of same names would be still unique.