Question: Doubled references when injecting about typedi HOT 3 CLOSED

@Service(...) boilerplate

The fact that you have to declare all services twice (once in the array of the @service([]) decorator and again in the constructor) is a bit off putting to me cause it's going to add a lot of boilerplate and it'll require quite a bit of effort to migrate.

It definitely means more boilerplate, but in my experience it's a lot easier to maintain than the original TypeDI. Issues like interfaces being represented as Object in the reflect metadata were initially quite hard to debug, and there were a lot of other pitfalls to the DX.

I'm not really sure what a better solution is, as of now; the current implementation is a lot easier in a few ways due to its avoidance of "magic" (e.g. reflect metadata), which can fail in unexpected and mysterious ways.

Typing / Runtime errors

Yeah, agreed -- this definitely needs an eager eye. Due to backwards compatibility with the original TypeDI (and due to TypeScript bugs), the Service decorator doesn't ensure the signature of the implementation's constructor aligns with that of the dependencies passed -- TypedService does, so it's a pretty welcome addition here.

Stage 3 Decorators

Is this a technical limitation of Stage 3 decorators or more of a design decision?

A design decision thus far. I haven't investigated much of the Stage 3 decorator surface, so I'm not entirely sure how well they jibe with experimental decorators' type metadata (and how well it works in general). I'm really looking to avoid the pitfalls of prior solutions altogether, as they can be very frustrating to debug (and can't really be flagged at compile time).

The package does support ES Decorators, but not property injection, etc. It just wraps the Service function to provide compatibility with the new decorator API.

inject(...)

@Service()
class RootService {
  private logger = inject(LogService);
}

I'm very heavily against this approach.
^{That links to a discussion I had regarding inject a while ago.}

It's effectively the service locator pattern: you're obscuring the dependencies of your class
by taking in a container and retrieving dependencies from it manually. That's the framework's
job, and in most DI solutions it does a much better job of it.

There are a few (practical, not just theoretical) issues with inject:

• The dependencies of services are obfuscated; now it takes in a container and does... something (this is called the service locator pattern). This is generally a bad idea, especially when working with external modules.
• It makes instantiating these classes (manually) much more confusing: do you need to setup global state? The state required now isn't explicitly in the class's signature, so you need to read the source code to understand how it works (eww).
• The framework has absolutely no idea what the class depends upon prior to instantiating it, so you lose out on any capacity to perform checks before accepting the class into a container.
• The beauty of this package is each class is dependencies in, service out: obscuring that contract is an anti-pattern, and it's something I'd rather not do just to save a few keystrokes.
• Some global state trickery would be required to use inject with non-default containers. It might even mean introducing a custom class instantiation function into the package, to set which container inject uses -- this is pretty gross.

So, inject is pretty much a no-go. Just too many pitfalls.
Interested in alternatives to cut down on boilerplate though.

Nevertheless, if you're hellbent on destruction, you could use HostContainer :-)

freshgum

from typedi.

You seem to be set on your way so I'm going to close this :)

Feel free to report any issues / ask more questions though!

from typedi.

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.

from typedi.