fiber: π [Bug]: Naming of routes works wrong after mount
Bug Description
Naming of routes after mounting sub-apps into root app works wrong. All routes turn into flat map of routes, but expected that they all separately work without any changing in original sub-apps. Also there is no way to set names of sub-apps (but it could be great, as groups have this feature).
How to Reproduce
Steps to reproduce the behavior:
- Create few sub-apps
- Setup some routes with names
- Add sub-apps to root app
- Try to use names in handlers or in main.go to find any Routes
Expected Behavior
Expected, that I can use naming in some sub-apps and it works. And after that if I mount sub-app to root-app, naming also works, but with correct prefixes (of paths and of names, like it works with groups).
I added some test, that could be placed into the end of app_test.go. Check if the proposal behaviour is correct.
Fiber Version
v2.50.0
Code Snippet (optional)
func Test_Mount_Route_Names(t *testing.T) {
// create sub-app with 2 handlers:
subApp1 := New()
subApp1.Name("app1.") // add some name to the app
subApp1.Get("/users", func(c *Ctx) error {
url, err := c.GetRouteURL("add-user", Map{})
utils.AssertEqual(t, nil, err)
utils.AssertEqual(t, "/app1/users", url, "handler: app1.add-user") // the prefix is /app1 because of the mount
// if subApp1 is not mounted, expected url just /users
return nil
}).Name("get-users")
subApp1.Post("/users", func(c *Ctx) error {
route := c.App().GetRoute("get-users")
utils.AssertEqual(t, MethodGet, route.Method, "handler: app1.get-users method")
utils.AssertEqual(t, "/app1/users", route.Path, "handler: app1.get-users path")
return nil
}).Name("add-user")
// create sub-app with 2 handlers inside a group:
subApp2 := New()
subApp2.Name("app2.") // add some name to the app
app2Grp := subApp2.Group("/users").Name("users.")
app2Grp.Get("", nil).Name("get")
app2Grp.Post("", nil).Name("add")
// put both sub-apps into root app
rootApp := New()
rootApp.Mount("/app1", subApp1)
rootApp.Mount("/app2", subApp2)
rootApp.startupProcess()
// take route directly from sub-app
route := subApp1.GetRoute("get-users")
utils.AssertEqual(t, MethodGet, route.Method)
utils.AssertEqual(t, "/users", route.Path)
route = subApp1.GetRoute("add-user")
utils.AssertEqual(t, MethodPost, route.Method)
utils.AssertEqual(t, "/users", route.Path)
// take route directly from sub-app with group
route = subApp2.GetRoute("users.get")
utils.AssertEqual(t, MethodGet, route.Method)
utils.AssertEqual(t, "/users", route.Path)
route = subApp2.GetRoute("users.add")
utils.AssertEqual(t, MethodPost, route.Method)
utils.AssertEqual(t, "/users", route.Path)
// take route from root app (using names of sub-apps)
route = rootApp.GetRoute("app1.add-user")
utils.AssertEqual(t, MethodPost, route.Method)
utils.AssertEqual(t, "/app1/users", route.Path)
route = rootApp.GetRoute("app2.users.add")
utils.AssertEqual(t, MethodPost, route.Method)
utils.AssertEqual(t, "/app2/users", route.Path)
// GetRouteURL inside handler
req := httptest.NewRequest(MethodGet, "/app1/users", nil)
_, _ = rootApp.Test(req)
// ctx.App().GetRoute() inside handler
req = httptest.NewRequest(MethodPost, "/app1/users", nil)
_, _ = rootApp.Test(req)
}
Checklist:
- I agree to follow Fiberβs Code of Conduct.
- I have checked for existing issues that describe my problem prior to opening this one.
- I understand that improperly formatted bug reports may be closed without explanation.
About this issue
- Original URL
- State: closed
- Created 8 months ago
- Comments: 18 (8 by maintainers)
Commits related to this issue
- π [Bug]: Naming of routes works wrong after mount #2688 — committed to gofiber/fiber by ReneWerner87 8 months ago
- π [Bug]: Naming of routes works wrong after mount #2688 (#2689) — committed to gofiber/fiber by ReneWerner87 8 months ago
When you work on the same app, expected that you control unique route names and any conflicts are on your focus. But when you mount some app into your app, it is better when you donβt check all route names, but just trust the framework to mount without bugs. I agree that now it is not a bug, but a feature π