add comment

Author: wxiaoguang

modules/web/router_path.go

@@ -37,6 +37,8 @@ func (g *RouterPathGroup) ServeHTTP(resp http.ResponseWriter, req *http.Request)
 	g.r.chiRouter.NotFoundHandler().ServeHTTP(resp, req)
 }
 
+// MatchPath matches the request method, and uses regexp to match the path.
+// The pattern uses "<...>" to define path parameters, for example: "/<name>" (different from chi router)
 func (g *RouterPathGroup) MatchPath(methods, pattern string, h ...any) {
 	g.processors = append(g.processors, newRouterPathMatcher(methods, pattern, h...))
 }

modules/web/router_test.go

@@ -38,6 +38,10 @@ func TestPathProcessor(t *testing.T) {
 		assert.True(t, p.matchPath(chiCtx, uri), "use pattern %s to process uri %s", pattern, uri)
 		assert.Equal(t, expectedPathParams, chiURLParamsToMap(chiCtx), "use pattern %s to process uri %s", pattern, uri)
 	}
+
+	// the "<...>" is intentionally designed to distinguish from chi's path parameters, because:
+	// 1. their behaviors are totally different, we do not to mislead developers
+	// 2. we can write regexp in "<name:\w{3,4}>" easily and parse it easily
 	testProcess("/<p1>/<p2>", "/a/b", map[string]string{"p1": "a", "p2": "b"})
 	testProcess("/<p1:*>", "", map[string]string{"p1": ""}) // this is a special case, because chi router could use empty path
 	testProcess("/<p1:*>", "/", map[string]string{"p1": ""})