Add option for inject to require a manually defined dependency.

[deebloo]

Add option for inject to require a manually defined dependency.

[deebloo]

that is true! you could pass something like that to the root injector by calling. I concede lol they are in fact related. implementing it this way also means you don't have to worry about passing an option every time you call inject

import { defineEnvironment } from "@joist/di";

defineEnvironment([{ provide: MyService, factory: () => throw new Error('Override expected!' }])

[deebloo]

@Phoscur I went ahead and published a minor version. https://www.npmjs.com/package/@joist/di

[Phoscur]

I hope this is related enough to not require its on issue (yet):

I've been testing around a bit today concerning reusing a ProviderToken and had not much success. So I'd like to suggest a custom factory

inject(MyPublicService, { factory: () => myGenericServiceInstance });
inject(MyOtherService, { factory: () => myGenericServiceInstance });

where myGenericServiceInstance implements MyPublicService as well as MyOtherService, and it's constructed in a different (static) way.
Can I expose an instance under two different ProviderTokens?

E.g. something like the following will result in two different ConsoleDebug instances:

  static providers = [{ provide: Debug, use: ConsoleDebug }];
  static providers = [{ provide: ConsoleDebug, use: ConsoleDebug }];

And this does not work:

  static providers = [{ provide: Debug, use: () => new ConsoleDebug() }];

Am I trying things I should not do anyways or am I just missing some more documentation?

Also, how do I access the fallback injector for my custom elements?

[deebloo]

Hmmm yeah currently there is no factory option because I couldn't find a reason to have one. So to restate your ask. You want two different tokens to return the same instance of a service.

I think a factory would be the best way to go here. Then you could return the same instance for both tokens. I think this would be a different issue.

I plan on spending some time on this soon (maybe this weekend?)

[Phoscur]

I still feel factory is very much related to fallback, if not you can still split the topics after your first iteration ;)

...so restate your ask. You want two different tokens to return the same instance of a service.

I don't think that's a good or at least not the only use case / example. However manually constructing the instance also allows to use constructor arguments, which I've been missing so far.
(I'm still looking for a nice example for this to share, but I'm still experimenting atm! :))

// building the injector procedurally
const inj = new Injector();
inj.set(MyService, (inj) => myServiceInstance);

// or supplying a factory in inject definition
#service = inject(MyService, factory: (inj) => new Decorator(inj.get(MyService)), fallback: false)); // MyService has a parent factory, fallback injector disallowed
// fallback: true (default) -> constructs MyService via fallback injector

// also need access to the fallback injector
inj.fallback.set(MyService, () => replacementInstance); // walks up injector parent chain to find the global shared fallback injector
// maybe fallback should be type boolean|factory?
#service = inject(MyService, fallback: () => fallbackInstance)

I plan on spending some time on this soon (maybe this weekend?)

Looking forward to your approach to this, don't get carried away by my ideas ;)

[deebloo]

Ha not at all. At a minimum I think a factory option makes sense.

[deebloo]

@Phoscur I have a PR open that allows you to define a factory method instead of use when defining a provider.

const debug = new ConsoleDebug();

@injectable
class MyElementCtx extends HTMLElement {
  static providers = [
    { provide: Debug, factory: () => debug },
    { provide: ConsoleDebug, factory: () => debug };
  ]
}

[deebloo]

I still think this particular issue is separate from requiring a manually defined parent and I should probably create a new issue

[Phoscur]

Allow the inject function to require a provider to be defined. This would mean no fall back to the global injector.

inject(MyService, { fallback: false })

In #966 you are hinting at an existing way of doing this:
inject(AbstractService) should fail to construct, so it requires configuring an override down the injector chain

And with this new feature, we can also provide a throwing factory:

providers: [{ provide: MyService, factory: () => throw new Error('Override expected!' }]