question: cannot upgrade to 0.10.0 due to @Service() being mandatory

[theodorDiaconu]

Description

class A {}
container.get(A); // now errors out because container wasn't set, or it doesn't have @Service()

@Service()
class Base {}

class Sub extends Base {}
container.get(Sub); // now errors out because container wasn't set, or it doesn't have @Service()

Is there any reason why we don't allow like in 0.8.0 ability to instantiate a class without the @Service part ?

[dittrichlucas]

I did a test with previous releases and I realized that this problem started with the 0.9.0 release (I am using 0.8.0)

[NoNameProvided]

This is by design, you need to add the @Service decorator to every class you want to inject or register it via:

Container.register({ id: MyClass, type: MyClass })

Is there any reason why we don't allow like in 0.8.0 ability to instantiate a class without the @Service part?

Yes, because attempting to inject anything you request without knowing how to actually initiate an instance leads to confusion and hard to debug errors down the line.

[theodorDiaconu]

Can we not allow a default strategy of instantiation or at least make it work when you’re inheriting a @service class? If this does not align with your vision I may have to use a fork, if it does I can submit a PR to allow an option to containerInstance how to get/instantiate things that aren’t registered.
Thank you!

[NoNameProvided]

I would rather not allow it as I believe it's flawed logic to blindly attempt to create the class, so I am afraid you have to fork the repo for yourself. The change you need to ake is rather simple in the last line of the ContainerInstance.get function instead of throwing an error just blindly call new identifier().

[theodorDiaconu]

(1)
I want to upgrade soon and I just realised it was a stupid idea to fork it. I can just override the get method, call the parent, catch ServiceNotFound, handle it manually, job done, zero headaches, using the nice stability features of 0.10+. What do you think?

(2)
Here's another interesting topic that I may have to work on, do you want to allow classes that inherit other classes to "copy" their metadata unless it isn't specified?

(3)
Why is it flawed logic? For me it feels natural that classes without specific metadata should act as singletons. @Service() feels extra for every little thing that I want in the container.

[NoNameProvided]

I want to upgrade soon and I just realised it was a stupid idea to fork it. I can just override the get method, call the parent, catch ServiceNotFound, handle it manually, job done, zero headaches, using the nice stability features of 0.10+. What do you think?

That can work.

Here's another interesting topic that I may have to work on, do you want to allow classes that inherit other classes to "copy" their metadata unless it isn't specified?

What do you mean by copy their metadata? It doesn't need to be copied because currently, we check for parent's metadata as well. Anyway, I am planning on changing a few stuff here, specifically storing the registered metadata for each class under its entry in the metadata storage and so any class can be resolved only via interacting with the metadata storage.

Why is it flawed logic? For me it feels natural that classes without specific metadata should act as singletons. @service() feels extra for every little thing that I want in the container.

It's not about being singleton, it's about not going the signature of the class being created.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.