Differences with ditox

[BANOnotIT]

Hello!

I saw a library called ditox which has almost same interface like your library do and several questions emerged:

1. Isn't .inSomeScope() more error prone then ditox's {scope:"some"} argument? I sometimes forgive to add these scope calls and only remember that when see warnings in console
2. Your approach for declaring injection gives people ability to declare it in place of Class declaration thus might lead to mix up DI and services. (this is already mentioned in DIP Violation #28). Ditox's approach with generating factories instead leans to group all DI-related declarations together.
3. Your tag based conditional injection is a great idea! Do you think factory based instance generation is a little bit more flexible?

I wrote this issue not to clash you and @mnasyrov but to know your position on these design decisions. I already use your library in some projects and it might be better for others who find your or ditox to know which one fits their case best.

P.S. @mnasyrov @vovaspace don't you think it'll be great to have links to each other's projects to increase awareness of options?

[vovaspace]

Hi. Thanks for your questions!

Isn't .inSomeScope() more error prone then ditox's {scope:"some"} argument?

You’re right. However, I can say “warning prone” rather than “error prone”.

I’m thinking about how to improve the DX of Brandi. Ditox’s approach looks great, I may will to implement a similar approach with a compile-time check.

Your approach for declaring injection gives people ability to declare it in place of Class declaration thus might lead to mix up DI and services.

You can call injected in any place of your app. Yes, it’s better to split class declaration and injecting, and inject near a container configuration. I’ll fix examples in documentation.

Your tag based conditional injection is a great idea! Do you think factory based instance generation is a little bit more flexible?

Thank you 🙏. Your idea about instance generation is not clear to me. Can you give an example?

[BANOnotIT]

Your idea about instance generation is not clear to me. Can you give an example?

// Define tokens for injections.
// Token can be optional to provide default values.
const TOKENS = {
  service: token<ServiceInterface>('Token description for debugging'),
};
const TAGS = {
  tag1: token<'val1' | 'val2'>('Token description for debugging'),
};


// Create the container.
const container = createContainer();

// Provide a value to the container.
container.bindValue(TAGS.tag1, 'val1')

// Dynamic values are provided by factories.
container.bindFactory(
  TOKENS.service,
  injectable((tag: 'val1' | 'val2') => tag === 'val1' ? new Service() : new MockService(), TAGS.tag1),
);

[mnasyrov]

Hello! As the author of Ditox.js, I'm happy to meet a library that shares similar concepts. It's interesting that although the development of both libraries was started around the same time, and different design decisions were applied, but the APIs share similar features and ideas. This allows to hope that the implemented APIs will be quite stable in the long run.

As for the functionality of the libraries - they differ in detail. For example, Ditox.js doesn't have capture() and restore() or "conditional bindings", because I think container is supposed to be a super simple thing and configuration by tags can be emulated by factories. Also, modules are described in different ways: declaratively in Ditox.js and imperatively in Brandi.