-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Factory like provider? #1099
Comments
Same concerns for us :) |
This is an interesting feature idea. I'll let the maintainers decide their route there, but until then, one thing you can do is this: Namespace your endpoints into their own Fx modules. fx.Module("endpoint1",
fx.Provide(NewEndpoint1),
) Once they're in their own modules, you can decorate the logger they receive with fx.Module("endpoint1",
fx.Provide(..),
fx.Decorate(func(log *zap.Logger) *zap.Logger {
return log.With(zap.String("endpoint", "endpoint1"))
}),
) The fx.Module will limit the scope of that decoration to just that endpoint. func EndpointLogger(name string) fx.Option {
fx.Decorate(func(log *zap.Logger) *zap.Logger {
return log.With(zap.String("endpoint", name))
})
}
// or even
func ProvideEndpoint(name string, ctor interface{}) fx.Option {
return fx.Module(name,
fx.Provide(ctor),
fx.Decorate(func(log *zap.Logger) *zap.Logger {
return log.With(zap.String("endpoint", name))
}),
)
} Hope this helps! |
Something with a smaller surface area that might be worth exploring here is some sort of module information struct passed to decorators. Strawman: type ModuleInfo struct {
Name string
Location Location
// other metadata about the module
} If a decorator has a ModuleInfo dependency, it will be invoked with information about the module scope where it's being applied. (This is just a strawman suggestion; not a real feature request.) |
Is your feature request related to a problem? Please describe.
current I have this kind of scenario, I have mutiple endpoints registers into fx and wil be mounted to a service
But all the endpoints receives the same logger. I would like it to invoke some kind of factory method that is aware of what and where an dependency is injected, thus each logger can be named one.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
Currently, it's being managed by hard coding.
Is this a breaking change?
No, This will be an additional feature
Additional context
.
The text was updated successfully, but these errors were encountered: