Skip to content

Conversation

@ReneWerner87
Copy link
Member

Summary

  • clarify the v2→v3 router diff to show the new RouteChain helper without implying Route was removed
  • point readers to both the RouteChain and Route API reference anchors for additional detail

Testing

  • GOVERSION=go1.25.1 make audit (fails: govulncheck forbidden to reach vuln.go.dev)
  • GOVERSION=go1.25.1 make generate
  • GOVERSION=go1.25.1 make betteralign
  • GOVERSION=go1.25.1 make modernize
  • GOVERSION=go1.25.1 make format
  • GOVERSION=go1.25.1 make test

https://chatgpt.com/codex/tasks/task_e_68d24f0a24c083269b2ba0c789065c70

@ReneWerner87 ReneWerner87 requested review from Copilot and removed request for Copilot September 23, 2025 11:27
@ReneWerner87 ReneWerner87 requested a review from a team as a code owner September 23, 2025 11:27
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Sep 23, 2025

Caution

Review failed

The pull request is closed.

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

Adds a chainable RouteChain(path string) Register and a callback-style Route(prefix string, fn func(router Router), name ...string) Router across App, Group, Router, and Register types; updates implementations, tests, and documentation to use RouteChain and to support prefix-based sub-router callbacks and optional naming. (50 words)

Changes

Cohort / File(s) Summary
App methods
app.go
Add func (app *App) RouteChain(path string) Register; add func (app *App) Route(prefix string, fn func(router Router), name ...string) Router; remove old Route(path string) Register.
Group methods
group.go
Add func (grp *Group) RouteChain(path string) Register; change Route to func (grp *Group) Route(prefix string, fn func(router Router), name ...string) Router (creates subgroup, optional name, invokes fn, returns subgroup).
Register / registering logic
register.go
Rename Register.RouteRegister.RouteChain; add group *Group to Registering; propagate group when constructing new Registering; update registration helpers to pass group context.
Router interface
router.go
Replace Route(path string) Register with RouteChain(path string) Register; add Route(prefix string, fn func(router Router), name ...string) Router.
Tests
app_test.go, middleware/cache/cache_test.go
Replace usages of Route(...) with RouteChain(...); rename Test_App_RouteTest_App_RouteChain; add tests exercising new Route(prefix, fn, name...) behavior and nil-func panics.
Docs
docs/api/app.md, docs/whats_new.md
Update examples and API docs to use RouteChain(...); add new Route(prefix, fn, name...) section and examples; update migration guidance and cross-links.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Dev as Developer
  participant App as App
  participant Group as Group/Sub-router
  participant Reg as Registering

  rect rgb(235,245,255)
  Dev->>App: Route(prefix, fn, name?)
  App->>Group: Group(prefix)
  alt name provided
    App->>Group: Name(name...)
  end
  App->>Group: Invoke fn(Group)
  Note right of Group: fn declares routes/subgroups on Group\n(callback-style grouping)
  end
Loading
sequenceDiagram
  autonumber
  participant Dev as Developer
  participant App as App
  participant Reg as Registering

  rect rgb(245,255,235)
  Dev->>App: RouteChain(path)
  App->>Reg: return Registering{app, group, path}
  Dev->>Reg: .Get/.Post/.Head/... (chained)
  Note right of Reg: Chained calls build nested route paths\nand register handlers fluently
  end
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Suggested labels

✏️ Feature, 📒 Documentation

Suggested reviewers

  • sixcolors
  • efectn
  • gaby

Poem

A rabbit hops through routes anew,
Chains click-clack and callbacks cue,
Prefixes planted, names tucked tight,
Sub-routers nest and paths take flight,
Hooray — the server hums tonight 🐇✨

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings, 1 inconclusive)
Check name Status Explanation Resolution
Description Check ⚠️ Warning The pull request description does not follow the repository’s required template: it only contains a Summary and Testing section and is missing the “# Description” overview, the “## Changes introduced” section with checkboxes, the “## Type of change” declaration, and the “## Checklist” items. Please revise the description to include all template sections, such as a clear “# Description” summary, a detailed “## Changes introduced” list with checkboxes, a “## Type of change” classification, and a completed “## Checklist” before merging.
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
Title Check ❓ Inconclusive The title “Update RouteChain function” is overly generic and does not clearly convey the full scope of the changes, which include renaming the existing Route helper to RouteChain, introducing a new Route(prefix, fn, name…) API, updating tests and documentation, and adjusting internal interfaces for the v3 router. Please choose a more descriptive title that succinctly captures the main changes, for example “Introduce RouteChain helper and new Route(prefix, fn) API in v3 router.”

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2e43105 and 2518a1e.

📒 Files selected for processing (1)
  • docs/whats_new.md (5 hunks)

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @ReneWerner87, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the routing API to provide clearer separation of concerns. It introduces RouteChain for defining a stack of handlers for a single route in a chainable manner, while restoring the Route method to its Fiber v2 functionality for defining routes with a common prefix using a function. This change aims to improve the API's intuitiveness and maintain backward compatibility for users accustomed to the v2 Route helper, ensuring that both common routing patterns are well-supported and distinctly named.

Highlights

  • Introduction of RouteChain: A new RouteChain method has been introduced in App, Group, and the Register interface. This method provides the chainable route declaration functionality, similar to Express's app.route, which was previously handled by the Route method.
  • Restoration of Route method behavior: The Route method on App and Group has been redefined to match its Fiber v2 behavior. It now accepts a prefix and a function to define routes within a common prefix, internally utilizing the Group method to create a sub-router.
  • Documentation Clarity: The documentation, including the API reference and the 'What's New' guide, has been updated to clearly distinguish between the RouteChain helper (for chaining handlers on the same path) and the Route helper (for prefix encapsulation).
  • Test Updates: Existing tests for the chainable route functionality have been updated to use RouteChain, and a new test has been added to cover the restored Route method's behavior.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@ReneWerner87 ReneWerner87 added this to the v3 milestone Sep 23, 2025
@ReneWerner87 ReneWerner87 linked an issue Sep 23, 2025 that may be closed by this pull request
3 tasks
@ReneWerner87
Copy link
Member Author

  • dont forget to change the migrator after merging the PR

@codecov
Copy link

codecov bot commented Sep 23, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.48%. Comparing base (edb585b) to head (2518a1e).
⚠️ Report is 22 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3761      +/-   ##
==========================================
+ Coverage   91.44%   91.48%   +0.04%     
==========================================
  Files         113      113              
  Lines       11824    11896      +72     
==========================================
+ Hits        10812    10883      +71     
  Misses        745      745              
- Partials      267      268       +1     
Flag Coverage Δ
unittests 91.48% <100.00%> (+0.04%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request effectively clarifies the distinction between RouteChain for method chaining and Route for route grouping, which was a point of confusion. The changes are consistent across the codebase, tests, and documentation. I've identified a couple of areas for improvement: adding nil checks in the new Route methods for robustness and updating external documentation links to be language-neutral. Overall, a great clarification.

@ReneWerner87
Copy link
Member Author

@hiifong what do you thing about this change? is the name okay for the new feature

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
register.go (1)

114-121: Group context is lost when chaining via RouteChain; carry Group through Registering

Registering currently doesn’t retain group, so routes created via grp.RouteChain(...) won’t have route.group set and won’t flip grp.anyRouteDefined. This breaks group name prefixing and related hooks/semantics.

Proposed changes (outside this hunk):

// register.go

// Extend Registering to carry group context
type Registering struct {
	app   *App
	group *Group
	path  string
}

// Ensure All/Add pass the group and set anyRouteDefined
func (r *Registering) All(handler Handler, handlers ...Handler) Register {
	r.app.register([]string{methodUse}, r.path, r.group, append([]Handler{handler}, handlers...)...)
	if r.group != nil && !r.group.anyRouteDefined {
		r.group.anyRouteDefined = true
	}
	return r
}

func (r *Registering) Add(methods []string, handler Handler, handlers ...Handler) Register {
	r.app.register(methods, r.path, r.group, append([]Handler{handler}, handlers...)...)
	if r.group != nil && !r.group.anyRouteDefined {
		r.group.anyRouteDefined = true
	}
	return r
}

// Use r.Add for GET to preserve group semantics (was calling app.Add directly)
func (r *Registering) Get(handler Handler, handlers ...Handler) Register {
	return r.Add([]string{MethodGet}, handler, handlers...)
}

And in group.go (within changed hunk below), initialize Registering with group set.

🧹 Nitpick comments (5)
register.go (1)

7-7: Nit: fix doc grammar

“generate by RouteChain()” → “generated by RouteChain()”.

Apply this diff:

-// Register defines all router handle interface generate by RouteChain().
+// Register defines the route registration interface generated by RouteChain().
group.go (1)

208-223: Optional: guard against nil callback

Avoid a panic if fn is nil.

Apply this diff:

 func (grp *Group) Route(prefix string, fn func(router Router), name ...string) Router {
+	if fn == nil {
+		return grp
+	}
 	// Create new group
 	group := grp.Group(prefix)
 	if len(name) > 0 {
 		group.Name(name[0])
 	}
 
 	// Define routes
 	fn(group)
 
 	return group
 }
app.go (1)

918-933: Route callback helper: LGTM; consider nil guard for parity with Group

Matches Router interface. Optional defensive nil check mirrors the suggestion in Group.

Apply this diff:

 func (app *App) Route(prefix string, fn func(router Router), name ...string) Router {
+	if fn == nil {
+		return app.Group(prefix)
+	}
 	// Create new group
 	group := app.Group(prefix)
 	if len(name) > 0 {
 		group.Name(name[0])
 	}
 
 	// Define routes
 	fn(group)
 
 	return group
 }
docs/whats_new.md (2)

331-336: Clarify the diff to show Route(prefix, fn, name...) was added, not removed.

The prose says Route remains available, but the diff block alone still reads like a removal. Show both additions to avoid misinterpretation.

Apply this diff to the code block:

-    Route(path string) Register
+    RouteChain(path string) Register
+    Route(prefix string, fn func(router Router), name ...string) Router

1678-1687: Remove trailing semicolon in Go example.

Go examples should avoid explicit semicolons for style consistency.

Apply this diff:

-    });
+    })
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between edb585b and 911317f.

📒 Files selected for processing (8)
  • app.go (1 hunks)
  • app_test.go (4 hunks)
  • docs/api/app.md (5 hunks)
  • docs/whats_new.md (4 hunks)
  • group.go (1 hunks)
  • middleware/cache/cache_test.go (2 hunks)
  • register.go (4 hunks)
  • router.go (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*.go: Format Go code using gofumpt (enforced via make format)
Ensure code passes golangci-lint checks (enforced via make lint)
Optimize struct field alignment using betteralign (enforced via make betteralign)
Modernize Go code using gopls modernize (enforced via make modernize)

Files:

  • group.go
  • middleware/cache/cache_test.go
  • app.go
  • register.go
  • router.go
  • app_test.go
docs/**

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Review and update the contents of the docs folder if necessary when modifying code

Files:

  • docs/whats_new.md
  • docs/api/app.md
🧠 Learnings (1)
📚 Learning: 2024-12-15T19:56:45.935Z
Learnt from: ckoch786
PR: gofiber/fiber#3230
File: docs/whats_new.md:944-951
Timestamp: 2024-12-15T19:56:45.935Z
Learning: Detailed usage examples and explanations for new methods like `RemoveRoute` and `RemoveRouteByName` are documented in `docs/api/app.md`, so it's unnecessary to duplicate them in `docs/whats_new.md`.

Applied to files:

  • docs/whats_new.md
  • docs/api/app.md
🧬 Code graph analysis (4)
group.go (2)
register.go (2)
  • Register (8-23)
  • Registering (29-33)
router.go (2)
  • Route (43-62)
  • Router (18-40)
app.go (3)
router.go (3)
  • App (366-385)
  • Route (43-62)
  • Router (18-40)
register.go (2)
  • Register (8-23)
  • Registering (29-33)
group.go (1)
  • Group (14-21)
router.go (1)
register.go (1)
  • Register (8-23)
app_test.go (1)
router.go (2)
  • Route (43-62)
  • Router (18-40)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: unit (1.25.x, windows-latest)
  • GitHub Check: repeated
  • GitHub Check: Compare
🔇 Additional comments (18)
router.go (1)

36-37: Interface additions LGTM; confirm all implementers updated

App and Group implement both methods. If there are other Router implementers (mocks, adapters), ensure they now satisfy the interface.

register.go (2)

22-22: API surface matches Router; good

RouteChain on Register aligns with Router interface.


38-47: Docs updated to RouteChain examples look good

Examples reflect the new helper correctly.

middleware/cache/cache_test.go (2)

878-878: Test update to RouteChain is correct

Chained Get/Head registration via RouteChain matches the new API.


907-907: LGTM: RouteChain usage

The replacement maintains behavior for HEAD→GET flow.

app.go (1)

908-916: RouteChain on App: LGTM

Constructor and scoping are correct; normalization happens in register().

docs/whats_new.md (3)

342-359: LGTM: concise RouteChain example.

Clear demonstration of chained registration with optional segments.


363-364: LGTM: Cross-links to API anchors.

Anchors align with the new sections in docs/api/app.md.


1658-1659: LGTM: Migration text correctly differentiates RouteChain vs Route.

Good clarification that Route preserves v2’s prefix behavior.

app_test.go (4)

1363-1379: LGTM: RouteChain basic chaining test covers all verbs.

Exercising all methods on the same path validates the new Register API well.


1390-1399: LGTM: Nested RouteChain("/v1") coverage.

Confirms nested chains work and handlers are reachable.


1400-1409: LGTM: Deeply nested RouteChain works as expected.

Trace and Get validations on v1/v2/v3 are solid.


1411-1432: LGTM: New Route(prefix, fn, name...) test proves preservation of v2-style grouping.

Nice touch verifying named routes resolve to expected paths.

docs/api/app.md (5)

141-149: LGTM: RouteChain signature is explicit and matches implementation.

Returning Register is clear and consistent with Router’s surface.


169-171: LGTM: Register interface includes RouteChain for nested chaining.

API surface is cohesive.


187-206: LGTM: Examples illustrate All + verb handlers and nested RouteChain.

Good parity with Express-style route stacks.


210-215: LGTM: Multi-method usage reads cleanly.

Matches the intended chainable ergonomics.


220-234: LGTM: Route(prefix, fn, name...) docs complete the picture.

Clear signature and example; aligns with Router interface and tests.

Copilot AI review requested due to automatic review settings September 23, 2025 11:44
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR clarifies documentation for the v2→v3 router migration by properly distinguishing between the new RouteChain helper and the existing Route function. The changes correct the documentation to show that Route was not removed but instead serves a different purpose, while RouteChain is the new helper for method chaining.

  • Renames Route method to RouteChain in the Router interface and implementations
  • Restores the original Route method for prefix encapsulation functionality
  • Updates documentation and examples to clearly differentiate the two helpers

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated no comments.

Show a summary per file
File Description
router.go Updates Router interface to include both RouteChain and Route methods
register.go Renames Route to RouteChain in Register interface and implementation
group.go Implements both RouteChain and Route methods with distinct purposes
app.go Implements both RouteChain and Route methods in the main App struct
docs/whats_new.md Clarifies migration documentation to show RouteChain as new addition
docs/api/app.md Updates API documentation with separate sections for RouteChain and Route
app_test.go Updates tests and adds separate test coverage for both methods
middleware/cache/cache_test.go Updates test calls to use RouteChain

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (4)
group.go (2)

202-203: Fix misleading comment

This creates a Registering, not a “group”.

-	// Create new group
+	// Create new registering helper

211-222: Guard against nil callback in Route

A nil fn will panic at call site; fail fast with a clear message.

 func (grp *Group) Route(prefix string, fn func(router Router), name ...string) Router {
+	if fn == nil {
+		panic("route handler 'fn' cannot be nil")
+	}
 	// Create new group
 	group := grp.Group(prefix)
 	if len(name) > 0 {
 		group.Name(name[0])
 	}
 
 	// Define routes
 	fn(group)
 
 	return group
 }
docs/whats_new.md (2)

341-359: Example is clear; small style nit

Go doesn’t need a trailing semicolon at the end of the chain; drop it for consistency.

-    })
-    .Post(func(c fiber.Ctx) error {
+    }).
+    Post(func(c fiber.Ctx) error {
         // Create user
         return c.JSON(fiber.Map{"message": "User created"})
-    })
+    })

1657-1659: RouteChain migration example: drop trailing semicolon

Minor style consistency with Go examples.

-    });
+    })

Also applies to: 1678-1687

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 911317f and 76c6a57.

📒 Files selected for processing (4)
  • app.go (1 hunks)
  • docs/api/app.md (5 hunks)
  • docs/whats_new.md (4 hunks)
  • group.go (1 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*.go: Format Go code using gofumpt (enforced via make format)
Ensure code passes golangci-lint checks (enforced via make lint)
Optimize struct field alignment using betteralign (enforced via make betteralign)
Modernize Go code using gopls modernize (enforced via make modernize)

Files:

  • group.go
  • app.go
docs/**

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Review and update the contents of the docs folder if necessary when modifying code

Files:

  • docs/api/app.md
  • docs/whats_new.md
🧠 Learnings (1)
📚 Learning: 2024-12-15T19:56:45.935Z
Learnt from: ckoch786
PR: gofiber/fiber#3230
File: docs/whats_new.md:944-951
Timestamp: 2024-12-15T19:56:45.935Z
Learning: Detailed usage examples and explanations for new methods like `RemoveRoute` and `RemoveRouteByName` are documented in `docs/api/app.md`, so it's unnecessary to duplicate them in `docs/whats_new.md`.

Applied to files:

  • docs/api/app.md
  • docs/whats_new.md
🧬 Code graph analysis (2)
group.go (2)
register.go (2)
  • Register (8-23)
  • Registering (29-33)
router.go (2)
  • Route (43-62)
  • Router (18-40)
app.go (3)
router.go (3)
  • App (366-385)
  • Route (43-62)
  • Router (18-40)
register.go (2)
  • Register (8-23)
  • Registering (29-33)
group.go (1)
  • Group (14-21)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Compare
  • GitHub Check: repeated
🔇 Additional comments (9)
app.go (2)

908-916: LGTM: App.RouteChain implementation

Straightforward constructor; aligns with Register API.


918-932: Add nil check for Route callback

Prevent accidental nil dereference; match Group.Route handling.

 func (app *App) Route(prefix string, fn func(router Router), name ...string) Router {
+	if fn == nil {
+		panic("route handler 'fn' cannot be nil")
+	}
 	// Create new group
 	group := app.Group(prefix)
 	if len(name) > 0 {
 		group.Name(name[0])
 	}
 
 	// Define routes
 	fn(group)
 
 	return group
 }
docs/whats_new.md (3)

331-336: Good clarification and link fix

Clear diff shows RouteChain addition without implying Route removal; Express link uses /en.


363-364: Nice cross-links to API reference

Anchors match the headings in docs/api/app.md.

If you want to double-check anchors resolve post-build, run the docs site locally and test these links.


367-373: Middleware alignment note reads well; Express link OK

No changes needed.

docs/api/app.md (4)

141-149: RouteChain section looks good; Express link corrected

API and signature align with code; link uses /en.


169-169: Register interface updated consistently

Includes RouteChain method; matches register.go.


187-215: Examples read well; consistent with chainable API

No issues; nice emphasis on “route-specific middleware”.


220-233: Route (prefix) docs: concise and accurate

Signature and naming example match implementation and group name semantics.

@ReneWerner87 ReneWerner87 changed the title Clarify RouteChain documentation diff Update RouteChain function Sep 23, 2025
@hiifong
Copy link

hiifong commented Sep 24, 2025

@hiifong what do you thing about this change? is the name okay for the new feature

It's perfect. Thank you so much for your work.

@gaby

This comment has been minimized.

@ReneWerner87
Copy link
Member Author

@coderabbitai What are your thoughts on the name "RouteChain"? Should we keep it, if not provide suggestions (and why).

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Sep 27, 2025

Tip

For best results, initiate chat on the files or code changes.

@ReneWerner87 I think "RouteChain" is actually a well-chosen name for several reasons:

Why "RouteChain" works well:

1. Semantic Clarity: The name clearly communicates the method's primary purpose - enabling method chaining for route registration. When developers see app.RouteChain("/api").Get(handler).Post(handler), the intent is immediately obvious.

2. Clear Differentiation: It effectively distinguishes itself from the new Route(prefix, fn, name...) method, which serves a completely different purpose (sub-router creation with callbacks). Having two distinct names prevents confusion about which API to use.

3. Descriptive of Behavior: The "Chain" suffix accurately describes what this method enables - chaining multiple HTTP method registrations in a fluent interface style.

4. Consistency with Intent: Looking at the usage patterns in the PR:

// Old: app.Route("/test").Get(...).Head(...).Post(...)
// New: app.RouteChain("/test").Get(...).Head(...).Post(...)

The name aligns perfectly with the chaining behavior.

Alternative considerations:

If we were to consider alternatives, options might include:

  • RouteBuilder() - emphasizes the builder pattern
  • Routes() - plural form suggesting multiple route registration
  • Path() - shorter, focuses on the path aspect

However, these alternatives have drawbacks:

  • "Builder" is more verbose and less intuitive
  • "Routes" could be confused with route retrieval methods
  • "Path" doesn't convey the chaining capability

Recommendation:

Keep "RouteChain" - it's intuitive, descriptive, and clearly differentiates from the callback-based Route method. The fact that hiifong also approved it reinforces that it resonates well with users.

The naming follows good API design principles: it's self-documenting and reduces cognitive load for developers transitioning from v2 to v3.

@gofiber gofiber deleted a comment from chatgpt-codex-connector bot Sep 27, 2025
@gaby gaby added this to v3 Sep 27, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
register.go (2)

7-8: Doc grammar nit in Register interface

Tighten wording for clarity.

-// Register defines all router handle interface generate by RouteChain().
+// Register defines the route handler interface generated by RouteChain().

Also applies to: 22-23


39-47: Example consistency: prefer Ctx within package examples

Inside package fiber examples, using Ctx instead of fiber.Ctx avoids confusion for readers copying snippets into this package.

-//  app.RouteChain("/").All(func(c fiber.Ctx) error {
+//  app.RouteChain("/").All(func(c Ctx) error {
 //       return c.Next()
 //  })
-//  app.RouteChain("/api").All(func(c fiber.Ctx) error {
+//  app.RouteChain("/api").All(func(c Ctx) error {
 //       return c.Next()
 //  })
-//  app.RouteChain("/api").All(handler, func(c fiber.Ctx) error {
+//  app.RouteChain("/api").All(handler, func(c Ctx) error {
 //       return c.Next()
 //  })
app.go (1)

908-916: App.RouteChain builder (no group) — LGTM

Correct to omit group here; callers get a path-scoped Register at app level.

After merge, remember to update the migrator as noted in PR comments so v2→v3 guidance reflects RouteChain/Route changes.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 76c6a57 and be5694f.

📒 Files selected for processing (3)
  • app.go (1 hunks)
  • group.go (1 hunks)
  • register.go (3 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*.go: Format Go code using gofumpt (enforced via make format)
Ensure code passes golangci-lint checks (enforced via make lint)
Optimize struct field alignment using betteralign (enforced via make betteralign)
Modernize Go code using gopls modernize (enforced via make modernize)

Files:

  • app.go
  • register.go
  • group.go
🧬 Code graph analysis (3)
app.go (3)
router.go (3)
  • App (366-385)
  • Route (43-62)
  • Router (18-40)
register.go (2)
  • Register (8-23)
  • Registering (29-34)
group.go (1)
  • Group (14-21)
register.go (3)
app.go (2)
  • App (68-110)
  • Handler (40-40)
group.go (1)
  • Group (14-21)
constants.go (1)
  • MethodGet (5-5)
group.go (2)
register.go (2)
  • Register (8-23)
  • Registering (29-34)
router.go (2)
  • Route (43-62)
  • Router (18-40)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: unit (1.25.x, macos-13)
  • GitHub Check: unit (1.25.x, windows-latest)
  • GitHub Check: repeated
  • GitHub Check: Compare
🔇 Additional comments (4)
group.go (2)

199-206: Group is now propagated in RouteChain — LGTM

The Registering is correctly scoped with group: grp, so chained routes inherit group name/hooks. This addresses prior feedback.

Run to double-check end-to-end propagation and detect any lingering old-style Route(...) chaining:

#!/bin/bash
set -euo pipefail

echo "== Ensure Group.RouteChain sets group =="
rg -nP 'func\s+\(grp\s+\*Group\)\s+RouteChain' group.go -n -C2
rg -nP 'Registering\{[^}]*group:\s*grp' group.go -n -C2

echo
echo "== Ensure Registering struct has group and all app.register calls use r.group =="
rg -nP 'type\s+Registering\s+struct\s*\{' register.go -n -C2
total=$(rg -n 'app\.register\(' register.go | wc -l | tr -d ' ')
with_group=$(rg -nP 'app\.register\([^)]*r\.group' register.go | wc -l | tr -d ' ')
echo "app.register calls: $total, with r.group: $with_group"
test "$total" = "$with_group" || { echo "Mismatch: some registrations may not pass r.group"; exit 1; }

echo
echo "== Find any old chaining via .Route(\"...\").Get/... =="
rg -nP '\.Route\(".*"\)\s*\.(All|Get|Head|Post|Put|Delete|Connect|Options|Trace|Patch)\(' -g '!**/vendor/**' -S || true

echo
echo "Done."

208-225: Route(prefix, fn, name...) adds nil-check and preserves naming — LGTM

Matches App.Route semantics and prevents accidental nil call.

register.go (1)

30-33: Group context propagation through Registering — LGTM

group *Group on Registering and forwarding r.group in All/Add/RouteChain are correct; ensures hooks/names/prefixing apply consistently to chained routes.

If more Registering helpers are added later, ensure they also pass r.group into app.register.

Also applies to: 51-53, 110-112, 114-121

app.go (1)

918-935: Route(prefix, fn, name...) with nil-check — LGTM

Matches Group.Route; panic message is consistent; optional name applied before fn.

github-actions[bot]

This comment was marked as outdated.

Copy link
Member

@gaby gaby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one small comment

@ReneWerner87 ReneWerner87 merged commit cd273d2 into main Sep 28, 2025
14 of 15 checks passed
@ReneWerner87 ReneWerner87 deleted the codex/2025-09-23-11-27-44 branch September 28, 2025 06:28
@github-project-automation github-project-automation bot moved this to Done in v3 Sep 28, 2025
Abhirup-99 pushed a commit to Abhirup-99/fiber that referenced this pull request Nov 3, 2025
* docs: clarify route helper diff

* Adjust Route docs to drop v2 mention and update Express links

* Harden route helpers and keep group context

* Clarify RouteChain diff in what's new guide

* docs: show RouteChain signature in migration notes

* Add coverage for Route helpers

* Clarify route chaining release wording
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

📝 [Proposal]: Retain v2 route signatures

4 participants