Mixing
GoLang go-cloud/wire problem with array as a parameter of Provider
I am having little trouble with correct configuration of wire I have following setup
Router
func NewRouter(routes RouterPath) AppRouter {
r := &appRouter{
routes: routes,
}
return r
}
Router interface
type RouterPath interface {
Register(root *mux.Router) (p *mux.Router)
}
and i do have few controllers that implement this interface
currently the best way how i find out how to make wire to solve DI was this
var routersSet = wire.NewSet(
routers.NewAuth,
routers.NewRoot,
routers.NewUser,
routers.NewPhpInfo,
)
func RouterProvider(info *routers.PhpInfo, root *routers.Root, user *routers.User) web.AppRouter {
routes := web.RouterPath{
info,
root,
user,
}
return routers.NewRouter(routes)
}
func Init() Kernel {
wire.Build(
routersSet,
RouterProvider,
NewKernel,
)
return nil
}
what i have problem with is that i had to make transition layer to NewRouter because it expects array of routes. Which will grow very easily and method definition will be horible to maintain. I would love to see smtg like put wire.ProviderSet into array and use that as a parameter of NewRouter but i could not figure how to do this.
Is there any better approach instead of this ?
go dependency-injection go-cloud
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
add a comment |
I am having little trouble with correct configuration of wire I have following setup
Router
func NewRouter(routes RouterPath) AppRouter {
r := &appRouter{
routes: routes,
}
return r
}
Router interface
type RouterPath interface {
Register(root *mux.Router) (p *mux.Router)
}
and i do have few controllers that implement this interface
currently the best way how i find out how to make wire to solve DI was this
var routersSet = wire.NewSet(
routers.NewAuth,
routers.NewRoot,
routers.NewUser,
routers.NewPhpInfo,
)
func RouterProvider(info *routers.PhpInfo, root *routers.Root, user *routers.User) web.AppRouter {
routes := web.RouterPath{
info,
root,
user,
}
return routers.NewRouter(routes)
}
func Init() Kernel {
wire.Build(
routersSet,
RouterProvider,
NewKernel,
)
return nil
}
what i have problem with is that i had to make transition layer to NewRouter because it expects array of routes. Which will grow very easily and method definition will be horible to maintain. I would love to see smtg like put wire.ProviderSet into array and use that as a parameter of NewRouter but i could not figure how to do this.
Is there any better approach instead of this ?
go dependency-injection go-cloud
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
add a comment |
I am having little trouble with correct configuration of wire I have following setup
Router
func NewRouter(routes RouterPath) AppRouter {
r := &appRouter{
routes: routes,
}
return r
}
Router interface
type RouterPath interface {
Register(root *mux.Router) (p *mux.Router)
}
and i do have few controllers that implement this interface
currently the best way how i find out how to make wire to solve DI was this
var routersSet = wire.NewSet(
routers.NewAuth,
routers.NewRoot,
routers.NewUser,
routers.NewPhpInfo,
)
func RouterProvider(info *routers.PhpInfo, root *routers.Root, user *routers.User) web.AppRouter {
routes := web.RouterPath{
info,
root,
user,
}
return routers.NewRouter(routes)
}
func Init() Kernel {
wire.Build(
routersSet,
RouterProvider,
NewKernel,
)
return nil
}
what i have problem with is that i had to make transition layer to NewRouter because it expects array of routes. Which will grow very easily and method definition will be horible to maintain. I would love to see smtg like put wire.ProviderSet into array and use that as a parameter of NewRouter but i could not figure how to do this.
Is there any better approach instead of this ?
go dependency-injection go-cloud
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
I am having little trouble with correct configuration of wire I have following setup
Router
func NewRouter(routes RouterPath) AppRouter {
r := &appRouter{
routes: routes,
}
return r
}
Router interface
type RouterPath interface {
Register(root *mux.Router) (p *mux.Router)
}
and i do have few controllers that implement this interface
currently the best way how i find out how to make wire to solve DI was this
var routersSet = wire.NewSet(
routers.NewAuth,
routers.NewRoot,
routers.NewUser,
routers.NewPhpInfo,
)
func RouterProvider(info *routers.PhpInfo, root *routers.Root, user *routers.User) web.AppRouter {
routes := web.RouterPath{
info,
root,
user,
}
return routers.NewRouter(routes)
}
func Init() Kernel {
wire.Build(
routersSet,
RouterProvider,
NewKernel,
)
return nil
}
what i have problem with is that i had to make transition layer to NewRouter because it expects array of routes. Which will grow very easily and method definition will be horible to maintain. I would love to see smtg like put wire.ProviderSet into array and use that as a parameter of NewRouter but i could not figure how to do this.
Is there any better approach instead of this ?
go dependency-injection go-cloud
go dependency-injection go-cloud
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
asked Nov 20 '18 at 16:16
Lukas ŠenfeldLukas Šenfeld
63
63
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
It's hard to see the whole picture of your application from just this small fragment, but it might be better to take in the dependencies of the routers that you're constructing into RouterProvider and just construct them in the function.
However, if you evaulate that and find that to be unsuitable, you still have some options. If you're only worried about the argument list to RouterProvider getting long, then you could use a struct provider:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
return routers.NewRouter(RouterPath{
r.Info,
r.Root,
r.User,
})
}
If this gets really unwieldy, you could use reflection to zip up the fields into a slice:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
value := reflect.ValueOf(r)
var paths RouterPath
for i := 0; i < value.NumField(); i++ {
if p, ok := value.Field(i).Interface().(RouterPath); ok {
paths = append(paths, p)
}
}
return routers.NewRouter(paths)
}
I'd really recommend the first approach though, because it's much more clear to someone reading your code what's going on. Reflection always moves breakages to run-time instead of compile-time.
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53397176%2fgolang-go-cloud-wire-problem-with-array-as-a-parameter-of-provider%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's hard to see the whole picture of your application from just this small fragment, but it might be better to take in the dependencies of the routers that you're constructing into RouterProvider and just construct them in the function.
However, if you evaulate that and find that to be unsuitable, you still have some options. If you're only worried about the argument list to RouterProvider getting long, then you could use a struct provider:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
return routers.NewRouter(RouterPath{
r.Info,
r.Root,
r.User,
})
}
If this gets really unwieldy, you could use reflection to zip up the fields into a slice:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
value := reflect.ValueOf(r)
var paths RouterPath
for i := 0; i < value.NumField(); i++ {
if p, ok := value.Field(i).Interface().(RouterPath); ok {
paths = append(paths, p)
}
}
return routers.NewRouter(paths)
}
I'd really recommend the first approach though, because it's much more clear to someone reading your code what's going on. Reflection always moves breakages to run-time instead of compile-time.
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
add a comment |
It's hard to see the whole picture of your application from just this small fragment, but it might be better to take in the dependencies of the routers that you're constructing into RouterProvider and just construct them in the function.
However, if you evaulate that and find that to be unsuitable, you still have some options. If you're only worried about the argument list to RouterProvider getting long, then you could use a struct provider:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
return routers.NewRouter(RouterPath{
r.Info,
r.Root,
r.User,
})
}
If this gets really unwieldy, you could use reflection to zip up the fields into a slice:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
value := reflect.ValueOf(r)
var paths RouterPath
for i := 0; i < value.NumField(); i++ {
if p, ok := value.Field(i).Interface().(RouterPath); ok {
paths = append(paths, p)
}
}
return routers.NewRouter(paths)
}
I'd really recommend the first approach though, because it's much more clear to someone reading your code what's going on. Reflection always moves breakages to run-time instead of compile-time.
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
add a comment |
It's hard to see the whole picture of your application from just this small fragment, but it might be better to take in the dependencies of the routers that you're constructing into RouterProvider and just construct them in the function.
However, if you evaulate that and find that to be unsuitable, you still have some options. If you're only worried about the argument list to RouterProvider getting long, then you could use a struct provider:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
return routers.NewRouter(RouterPath{
r.Info,
r.Root,
r.User,
})
}
If this gets really unwieldy, you could use reflection to zip up the fields into a slice:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
value := reflect.ValueOf(r)
var paths RouterPath
for i := 0; i < value.NumField(); i++ {
if p, ok := value.Field(i).Interface().(RouterPath); ok {
paths = append(paths, p)
}
}
return routers.NewRouter(paths)
}
I'd really recommend the first approach though, because it's much more clear to someone reading your code what's going on. Reflection always moves breakages to run-time instead of compile-time.
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
It's hard to see the whole picture of your application from just this small fragment, but it might be better to take in the dependencies of the routers that you're constructing into RouterProvider and just construct them in the function.
However, if you evaulate that and find that to be unsuitable, you still have some options. If you're only worried about the argument list to RouterProvider getting long, then you could use a struct provider:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
return routers.NewRouter(RouterPath{
r.Info,
r.Root,
r.User,
})
}
If this gets really unwieldy, you could use reflection to zip up the fields into a slice:
type routers struct {
Info *routers.PhpInfo
Root *routers.Root
User *routers.User
}
func RouterProvider(r routers) web.AppRouter {
value := reflect.ValueOf(r)
var paths RouterPath
for i := 0; i < value.NumField(); i++ {
if p, ok := value.Field(i).Interface().(RouterPath); ok {
paths = append(paths, p)
}
}
return routers.NewRouter(paths)
}
I'd really recommend the first approach though, because it's much more clear to someone reading your code what's going on. Reflection always moves breakages to run-time instead of compile-time.
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
answered Jan 15 at 22:58
Ross LightRoss Light
2,5901526
2,5901526
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53397176%2fgolang-go-cloud-wire-problem-with-array-as-a-parameter-of-provider%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
