About factory provider design, why can not direct set as singleton.

class FooList {
  public void add(str: string) {}
}
di.register<FooList>(
  FooList, 
  {
    useFactory: (d) => {
      const obj = new FooList();
      obj.add('foo1');
      return obj;
    }
  },
 {singleton: true}
); 

const result1 = di.resolve<FooList>(FooList);
const result2 = di.resolve<FooList>(FooList);

console.log(result1 === result2); 

Expected Behavior

Console result: true

Current Behavior

Throw: Cannot use {singleton: true} with ValueProviders or FactoryProviders

Solution

Use TokenProvider again.

di.register<FooList>(
  'FooListFactory', 
  {
    useFactory: (d) => {
      const obj = new FooList();
      obj.add('foo1');
      return obj;
    }
  }
);
di.register<FooList>(
  FooList, 
  {useToken:  'FooListFactory',},
  {singleton: true}
);

But, why can not direct set it.

Is it a bug ? Or some problem of design?

[spikyjt]

I appreciate this is old, but who says we want to use a factory to instantiate an instance each time we resolve a token? What if we want a singleton which requires some specific set up (i.e. not just mapped to any old instance of a class) but we don’t want to do that set up at registration, preferring to delay it until first resolution? This could be particularly useful if the set up is heavy and we either don’t want it to happen at the start or even at all if unused. Perhaps there is another way to achieve this?

[mikl]

Ditto here, I’ve been using useFactory to construct non-class things, like this:

function loggerFactory(conf: Configuration) {

  return createLogger({
    level: conf.get<string>('logLevel')
  })
}

container.register<Logger>(LOGGER, {
  useFactory: (dc) => loggerFactory(dc.resolve(Configuration))
})

Having to wrap that in instanceCachingFactory does work:

container.register<Logger>(LOGGER, {
  useFactory: instanceCachingFactory<Logger>((dc) =>
    loggerFactory(dc.resolve(Configuration))
  )
})

…but it would be better ergonomics if there was an option for this.