You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having used other popular dependency injection libraries for other languages, I find the use of the name Component a little misleading. My understanding is that, what is annotated with #[derive(Component)] will survive for the rest of the application runtime, with no other scope, which is what a singleton does and would match the javax.inject.Singleton behavior.
I based the naming of "component" on how Spring and Autofac name the "service" classes "components". Dagger's naming in general seems to be a bit different than the rest of the DI libraries, so maybe a better name would be "Service", as that seems to be one thing all of the libraries have in common.
I think this issue should also include the name for what are currently called "providers". Some other possible names include "factories" and "scoped services" (scoping is another topic, but maybe better handled in a separate issue).
FYI calling it a Service will conflict with the naming conventions of the axum crate, which uses that word for its transitive dependency crate, tower-service, and uses it as part of its own Router APIs.
Having used other popular dependency injection libraries for other languages, I find the use of the name
Component
a little misleading. My understanding is that, what is annotated with#[derive(Component)]
will survive for the rest of the application runtime, with no other scope, which is what a singleton does and would match thejavax.inject.Singleton
behavior.Dagger uses the name
Component
for something very different, that is way similar to what the shaku'smodule!
macro does: https://developer.android.com/training/dependency-injection/dagger-basics#dagger-componentsThe text was updated successfully, but these errors were encountered: