-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
refactor: wrap handler function in a separate type #20
Conversation
WalkthroughThe pull request introduces significant changes to the method signatures of the Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this 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
🧹 Outside diff range and nitpick comments (3)
plugins/plugin.go (1)
8-8
: LGTM! Good architectural improvement.The change to use
req.Handler
type instead of an inline function signature is a positive architectural improvement that:
- Makes the code more maintainable
- Reduces duplication
- Makes future modifications to handler behavior easier
- Improves type safety
Consider documenting this change in the package documentation to help other developers understand the handler pattern.
router/app.go (2)
Line range hint
47-66
: Add nil handler validation.The signature change to
req.Handler
looks good and improves type consistency. However, consider adding validation for nil handlers to prevent runtime panics.func (a *App) Route(method, path string, handler req.Handler) { + if handler == nil { + panic("handler cannot be nil") + } if a.routes[path] == nil { a.routes[path] = make(map[string]http.HandlerFunc) }
Line range hint
47-100
: Document the handler type change and add migration guide.While the refactor improves the codebase, it introduces a breaking change in the API. Consider:
- Adding godoc comments explaining the
req.Handler
type usage- Creating a migration guide for updating existing handlers
- Adding examples of handler implementation with the new type
Add documentation like this to the Route method:
+// Route registers a new handler for the given method and path. +// The handler must implement the req.Handler type. +// Example: +// app.Route("GET", "/hello", func(req *req.Request, res *req.Response) { +// res.Text(200, "Hello, World!") +// }) func (a *App) Route(method, path string, handler req.Handler) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
plugins/plugin.go
(1 hunks)req/types.go
(1 hunks)router/app.go
(2 hunks)
✅ Files skipped from review due to trivial changes (1)
- req/types.go
🔇 Additional comments (1)
router/app.go (1)
67-100
: Verify handler type changes across the codebase.
The consistent implementation of HTTP method handlers using req.Handler
looks good. However, this change might impact existing code that uses these methods.
Let's verify the impact of these changes:
✅ Verification successful
Based on the search results, I can now generate the final response:
No breaking changes detected - handler signatures are consistent
The codebase already consistently uses the req.Handler
signature (func(req *req.Request, res *req.Response)
) across all route handlers. This includes:
- Test files in
router/router_test.go
- Example implementations in the
examples/
directory - Handler type definition and route creation in the core code
The changes to the HTTP method handlers are safe as they align with the existing handler implementations throughout the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for existing handler function declarations that might need updating
# Look for old-style handler declarations that need to be updated to req.Handler
echo "Searching for potential handler implementations that need updating..."
rg -t go "func.*\*req\.Request.*\*req\.Response" --no-filename
echo "Searching for direct usage of these router methods..."
rg -t go "(\w+)\.(Get|Post|Put|Delete|Patch|Options|Head|Connect|Trace)\s*\(" -A 3
Length of output: 4751
@@ -5,5 +5,5 @@ import ( | |||
) | |||
|
|||
type Plugin interface { | |||
Register(route func(method, path string, handler func(req *req.Request, res *req.Response))) | |||
Register(route func(method, path string, handler req.Handler)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Codebase verification
Based on the shell script results, I can generate the final response:
Plugin interface implementations are inconsistent with the new signature
The current implementations of the Plugin interface have different signatures than the one defined in plugins/plugin.go
:
plugins/plugin_test.go
: MockPlugin usesfunc(req *req.Request, res *MockResponse)
as handler- Examples in
CHANGELOG.md
anddoc/plugins.md
usefunc(req *req.Request, res *req.Response)
as handler - But the interface in
plugins/plugin.go
defines it asreq.Handler
The implementations need to be updated to use the new req.Handler
type consistently.
🔗 Analysis chain
Verify Plugin interface implementations.
Let's ensure all implementations of the Plugin interface have been updated to match the new signature.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find all implementations of the Plugin interface to verify they've been updated
# Search for struct types that might implement the Plugin interface
ast-grep --pattern 'type $_ struct {
$$$
}'
# Search for Register method implementations
rg -A 5 'func \(.*\) Register\('
Length of output: 4360
Thanks for the contribution ❤️ |
Description
If I used the LSP autofill and used the default variable names, the suggestions would conflict as
req
is also a package name. So I renamed the arguments and wrapped function in a separate type to simplify further modificationsRelated Issues (if any)
Type of Changes
Please mark the options that best describe your PR:
Checklist
go test ./...
).README.md
, code comments).Additional Notes
Summary by CodeRabbit
New Features
req
package with a standardizedHandler
type for request handling.Improvements
req.Handler
type, enhancing consistency in handler definitions.Bug Fixes