ctx.go (2)

886-902: LGTM! Consider adding a brief comment.

The implementation of the CBOR method looks good. It follows the pattern of similar methods like JSON, handles errors appropriately, and allows for custom content types. The use of SetBodyRaw is efficient for setting the response body.

Consider adding a brief comment explaining the purpose of this method, similar to other methods in this file. For example:

// CBOR converts any interface or string to CBOR encoded bytes and sets it as the response body.
// If the ctype parameter is given, it sets the Content-Type header to the provided value.
// Otherwise, it sets the Content-Type header to "application/cbor".
func (c *DefaultCtx) CBOR(data any, ctype ...string) error {
    // ... (existing implementation)
}

---

Line range hint 1048-1066: Consider improving error handling in the JSON method

For consistency with the newly added CBOR method, consider updating the JSON method to return an error. This would allow for better error handling when JSON encoding fails.

Here's a suggested modification to the JSON method:

-func (c *DefaultCtx) JSON(data any, ctype ...string) error {
+func (c *DefaultCtx) JSON(data any, ctype ...string) error {
 	raw, err := c.app.config.JSONEncoder(data)
 	if err != nil {
-		return err
+		return fmt.Errorf("failed to encode JSON: %w", err)
 	}
 	c.fasthttp.Response.SetBodyRaw(raw)
 	if len(ctype) > 0 {
 		c.fasthttp.Response.Header.SetContentType(ctype[0])
 	} else {
 		c.fasthttp.Response.Header.SetContentType(MIMEApplicationJSON)
 	}
 	return nil
 }

This change would make the error handling more informative and consistent with the new CBOR method.

app.go (1)

321-334: Ensure comments for CBOR encoder and decoder fields are clear and consistent

The comments for CBOREncoder and CBORDecoder in the Config struct could be improved for clarity and consistency with existing documentation comments. Consider revising the comments to match the style of other encoder/decoder fields.

Apply this diff to adjust the comments:

321,325c321,325
-	// When set by an external client of Fiber it will use the provided implementation of a
-	// CBORMarshal
-	//
-	// Allowing for flexibility in using another cbor library for encoding
-	// Default: cbor.Marshal
+	// When set by an external client of Fiber, it will use the provided implementation of a
+	// CBORMarshal.
+	//
+	// Allowing for flexibility in using another CBOR library for encoding.
+	// Default: cbor.Marshal

Similarly, adjust the comments for CBORDecoder:

328,333c328,333
-	// When set by an external client of Fiber it will use the provided implementation of a
-	// CBORUnmarshal
-	//
-	// Allowing for flexibility in using another cbor library for decoding
-	// Default: cbor.Unmarshal
+	// When set by an external client of Fiber, it will use the provided implementation of a
+	// CBORUnmarshal.
+	//
+	// Allowing for flexibility in using another CBOR library for decoding.
+	// Default: cbor.Unmarshal

Configuration used: CodeRabbit UI
Review profile: CHILL

Configuration used: CodeRabbit UI
Review profile: CHILL

docs/whats_new.md (5)

199-200: Consider expanding the CBOR documentation

The introduction of CBOR support is a significant feature that aligns well with the PR objectives. To ensure users can fully leverage this new capability, consider expanding the documentation with:

1. A brief explanation of what CBOR is and its benefits.
2. An example of how to use the new CBOR method.
3. Any performance considerations or best practices for using CBOR in Fiber.

This additional information would help users understand and adopt the new feature more easily.

Also applies to: 213-213

---

Line range hint 76-91: Enhance explanation of Router changes

The updates to the Router interface, particularly the changes to HTTP method registration and the new Route chaining, are significant improvements. To help users better understand and appreciate these changes, consider:

1. Explaining the benefits of making the handler mandatory in the method signatures (e.g., improved type safety, clearer API).
2. Providing a brief comparison of the old and new Route chaining syntax, highlighting how it improves code readability and maintainability.
3. Adding a note on any potential breaking changes these updates might cause for existing codebases.

These additions would provide more context and help users understand why these changes were made and how they can benefit from them.

Also applies to: 96-102

🧰 Tools

🪛 LanguageTool

[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...

(NODE_JS)

---

Line range hint 252-254: Expand the Client package section

The Client package rebuild seems to be a major update in Fiber v3. To give users a better understanding of these changes, consider:

1. Listing a few key new features or improvements (e.g., Cookiejar, request/response hooks) with brief explanations.
2. Providing a simple before-and-after code example to illustrate how the usage of the Client package has changed.
3. Mentioning any performance improvements or changes in behavior that users should be aware of.

This additional information would help users quickly grasp the significance of the Client package updates and how they might affect their existing code.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...

(NODE_JS)

---

Line range hint 321-326: Clarify middleware changes and migration steps

The updates to various middlewares represent significant changes in Fiber v3. To ensure a smooth transition for users, consider:

1. For the Filesystem middleware removal:

   • Explain the rationale behind merging it into the Static middleware.
   • Provide a more detailed example of how to migrate from Filesystem to Static, covering common use cases.

2. For the Monitor middleware move to Contrib:

   • Explain why this change was made (e.g., to keep the core lighter, to allow for more frequent updates).
   • Provide clear instructions on how to install and import the Contrib package.

3. For other middleware updates (e.g., Adaptor, CORS):

   • Highlight any potential breaking changes.
   • Provide before-and-after examples for common configurations.

These additions would help users understand the impact of these changes and how to update their existing code effectively.

Also applies to: 410-416, 495-507

🧰 Tools

🪛 LanguageTool

[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...

(NODE_JS)

---

Line range hint 509-515: Enhance the migration guide structure and content

The migration guide is a crucial resource for users upgrading to Fiber v3. To make it even more effective, consider the following improvements:

1. Add a brief introduction explaining the scope of changes in v3 and who needs to pay attention to which sections.
2. Include a "Quick Start" section for users with simpler applications, highlighting the most common and critical changes.
3. For each major change, provide:
   • A brief explanation of why the change was made.
   • A complete before-and-after code example.
   • Any gotchas or common pitfalls to watch out for during migration.
4. Add a "Troubleshooting" section addressing common issues users might encounter during the upgrade process.
5. Consider adding a "Deprecation Timeline" for any features that are being phased out but not immediately removed in v3.

These enhancements would make the migration guide more user-friendly and comprehensive, helping to ensure a smoother transition for all Fiber users.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...

(NODE_JS)

Configuration used: CodeRabbit UI
Review profile: CHILL

docs/whats_new.md (4)

199-200: Enhance CBOR documentation with examples and configuration options.

The CBOR feature introduction would benefit from:

1. Code examples showing usage
2. Configuration options (if any)
3. Performance characteristics compared to JSON/XML

Add a code example like this:

// Example CBOR usage
app.Get("/", func(c *fiber.Ctx) error {
    data := map[string]interface{}{
        "message": "Hello, World!",
        "number": 42,
    }
    return c.CBOR(data)
})

---

213-213: Cross-reference CBOR method in Context section.

The CBOR method listing should include a link to its detailed API documentation and mention any available configuration options.

Update the line to:

-CBOR -> for CBOR encoding
+CBOR -> for CBOR encoding (see [CBOR API documentation](./api/ctx.md#cbor))

---

Line range hint 1-24: Consider adding version compatibility matrix.

The introduction section would benefit from a clear compatibility matrix showing:

1. Go version requirements
2. Breaking changes overview
3. Deprecation timeline for v2

Add a compatibility matrix like:

| Fiber Version | Go Version | Status      |
|--------------|------------|-------------|
| v3.x         | ≥ 1.22     | Current     |
| v2.x         | ≥ 1.17     | Maintenance |

🧰 Tools

🪛 LanguageTool

[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...

(NODE_JS)

---

Line range hint 12-24: Update table of contents to match actual content.

The table of contents is missing some sections that are present in the document:

1. Drop for old Go versions
2. Generic functions

Update the table of contents to include all sections and maintain consistent ordering with the document body.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~203-~203: The official spelling of this programming framework is “Express.js”.
Context: ...ions. ### new methods - AutoFormat -> ExpressJs like - Host -> ExpressJs like - Port ->...

(NODE_JS)

Configuration used: CodeRabbit UI
Review profile: CHILL

binder/cbor.go (1)

1-15: Consider adding unit tests and documentation.

As this is a new binding implementation, please ensure:

1. Add comprehensive unit tests covering both success and error cases
2. Add godoc comments explaining the binding's purpose and usage
3. Update the framework's documentation to include CBOR binding examples
4. Consider adding benchmarks to compare with other binding implementations

Would you like me to help generate:

1. Unit test cases?
2. Documentation examples?
3. Benchmark tests?

client/response.go (1)

78-81: Enhance method documentation for better clarity.

The implementation looks good and follows the established pattern of other unmarshal methods. Consider enhancing the documentation to provide more details about the CBOR unmarshaling process and any potential errors that might be returned.

-// CBOR method will unmarshal body to cbor.
+// CBOR method unmarshals the response body as CBOR into the given value.
+// It uses the client's CBOR unmarshaler to decode the response body.
+// Returns an error if the unmarshaling fails.

bind.go (1)

123-128: Add documentation and ensure test coverage.

Please consider the following improvements:

1. Add documentation comments for the CBOR method explaining:
   • Purpose and usage
   • Any specific CBOR encoding considerations
   • Example usage if helpful
2. Ensure comprehensive test coverage in bind_test.go:
   • Basic CBOR binding
   • Error cases
   • Performance benchmarks comparing with JSON

Example documentation:

+// CBOR binds CBOR-encoded body data into the provided struct.
+// The binding uses the application's configured CBORDecoder for custom decoding if provided.
 func (b *Bind) CBOR(out any) error {

client/hooks.go (1)

133-134: Consider setting Accept header for consistency

While the CBOR case correctly sets the Content-Type header, consider setting the Accept header to match the pattern used in the JSON case for consistency:

 case cborBody:
   req.RawRequest.Header.SetContentType(applicationCBOR)
+  req.RawRequest.Header.Set(headerAccept, applicationCBOR)

client/client.go (2)

155-175: Fix documentation comments referencing XML instead of CBOR

The documentation comments for CBOR methods incorrectly reference XML. This should be updated to maintain accuracy.

Update the comments as follows:

-// CBORMarshal returns xml marshal function in Core.
+// CBORMarshal returns CBOR marshal function in Core.

-// SetCBORMarshal Set xml encoder.
+// SetCBORMarshal Set CBOR encoder.

-// CBORUnmarshal returns xml unmarshal function in Core.
+// CBORUnmarshal returns CBOR unmarshal function in Core.

-// SetCBORUnmarshal Set xml decoder.
+// SetCBORUnmarshal Set CBOR decoder.

---

Line range hint 607-608: Consider adding CBOR support to Config struct

The Config struct and setConfigToRequest function currently default to JSON serialization for the Body field. Consider adding support for CBOR serialization to maintain consistency with the new CBOR functionality.

Consider adding a field to specify the serialization format:

 type Config struct {
     Body      any
+    // BodyFormat specifies the serialization format (e.g., "json", "xml", "cbor")
+    BodyFormat string
     // ... rest of the fields
 }

Then update setConfigToRequest:

 if cfg.Body != nil {
+    switch cfg.BodyFormat {
+    case "cbor":
+        req.SetCBOR(cfg.Body)
+    case "xml":
+        req.SetXML(cfg.Body)
+    default:
         req.SetJSON(cfg.Body)
+    }
     return
 }

client/request.go (2)

341-345: Add documentation comments for consistency.

Other methods in this file include documentation comments. Consider adding a comment to describe the CBOR functionality:

+// SetCBOR method sets CBOR body in request.
 func (r *Request) SetCBOR(v any) *Request {

---

341-345: LGTM! Consider adding validation for better error handling.

The implementation correctly follows the established pattern. However, consider adding validation to ensure the input can be properly encoded to CBOR:

 func (r *Request) SetCBOR(v any) *Request {
+    if v == nil {
+        return r
+    }
     r.body = v
     r.bodyType = cborBody
     return r
 }

bind_test.go (3)

15-15: Use an import alias for clarity

Consider adding an alias for the cbor package to improve code readability and avoid potential naming conflicts.

Apply this diff to add an import alias:

-	"github.com/fxamacker/cbor/v2"
+	cbor "github.com/fxamacker/cbor/v2"

---

1103-1131: Handle errors consistently in benchmarks

In the Benchmark_Bind_Body_CBOR function, consider using b.Fatalf instead of b.Error to halt the benchmark immediately if marshalling fails. This ensures that the benchmark does not continue running with invalid data.

Apply this diff for consistent error handling:

 body, err := cbor.Marshal(&Demo{Name: "john"})
 if err != nil {
-	b.Error(err)
+	b.Fatalf("Failed to marshal CBOR data: %v", err)
 }

---

1751-1760: Avoid duplicating error handling code

Extract the CBOR marshalling and error handling into a helper function to reduce code duplication and improve maintainability.

Create a helper function:

func marshalCBOR(t *testing.T, v interface{}) []byte {
	enc, err := cbor.Marshal(v)
	if err != nil {
		t.Fatal(err)
	}
	return enc
}

Modify your test code to use the helper function:

-	cb, err := cbor.Marshal(&Request{
+	cb := marshalCBOR(t, &Request{
 	BodyParam: "body_param",
-})
-if err != nil {
-	t.Error(err)
-}
+})

Update the call to testDecodeParser:

-	testDecodeParser(MIMEApplicationCBOR, string(cb))
+	testDecodeParser(MIMEApplicationCBOR, cb)

Ensure testDecodeParser accepts a byte slice:

-func testDecodeParser(contentType, body string) {
+func testDecodeParser(contentType string, body []byte) {

Configuration used: CodeRabbit UI
Review profile: CHILL

func (*cborBinding) Bind(body []byte, cborDecoder utils.CBORUnmarshal, out any) error {
+	if len(body) == 0 {
+		return nil
+	}
+	if cborDecoder == nil {
+		return fmt.Errorf("cbor decoder is nil")
+	}
+	if out == nil {
+		return fmt.Errorf("output parameter is nil")
+	}
	return cborDecoder(body, out)
}

#!/bin/bash
# Description: Check how other binders handle validation
# Test: Look for similar validation patterns in other binders
rg -A 5 'func.*Bind.*\(.*\).*error' binder/

#!/bin/bash
# Description: Check for the existence and implementation of cborUnmarshal in the Client struct

# Search for cborUnmarshal definition
echo "Searching for cborUnmarshal implementation..."
ast-grep --pattern 'func (c *Client) cborUnmarshal($_, $_) error'

# Search for CBOR-related imports
echo "Checking for CBOR-related imports..."
rg 'import.*cbor'

#!/bin/bash
# Let's try a broader search for CBOR-related code and implementations

# Search for any CBOR-related function definitions
echo "Searching for CBOR-related function implementations..."
ast-grep --pattern 'func $_($$$) $_($$$) {
  $$$
  cbor$$$
  $$$
}'

# Search for any CBOR usage in the codebase
echo "Searching for CBOR usage in the codebase..."
rg -i "cbor" -A 3

# Search for unmarshal-related functions in client
echo "Searching for unmarshal functions in client..."
fd -e go -x grep -l "unmarshal" {} \; | xargs rg "func.*[Uu]nmarshal"

#!/bin/bash
# Description: Verify CBOR MIME type constant definition and usage
# Expected: Should find MIMEApplicationCBOR constant definition with value "application/cbor"

# Search for MIMEApplicationCBOR constant definition
rg "MIMEApplicationCBOR.*=.*\"application/cbor\""

# Search for other usages of this constant
rg "MIMEApplicationCBOR"

#!/bin/bash
# Description: Verify CBORDecoder initialization in app.go
# Expected: Should find CBORDecoder initialization in Config struct and default configuration

# Search for CBORDecoder in Config struct and its initialization
rg -A 5 "CBORDecoder"

#!/bin/bash
# Let's search for CBORDecoder in the codebase
rg -A 5 "CBORDecoder"

# Also search for CBOR-related configuration
ast-grep --pattern 'type Config struct {
  $$$
  CBORDecoder $_ 
  $$$
}'

# Check for any default CBOR decoder initialization
rg -A 5 "func New|func Config"

#!/bin/bash
# Description: Verify the implementation of cborMarshal function
# Expected: Should find the implementation of cborMarshal in the client package

# Search for cborMarshal implementation
echo "Searching for cborMarshal implementation..."
rg -p "func.*cborMarshal" --type go

# Search for CBOR-related imports to verify the marshaling library
echo "Checking CBOR-related imports..."
rg "import.*cbor" --type go

#!/bin/bash
# Let's try a broader search for CBOR-related code and the cborMarshal method

# Search for any CBOR-related code
echo "Searching for any CBOR references..."
rg -i "cbor" --type go -A 5 -B 5

# Search for method definitions in the client struct
echo "Searching for client struct methods..."
ast-grep --pattern 'func (c *Client) $_($$$) $$$'

# Look for any marshal-related functions
echo "Searching for marshal-related functions..."
rg "func.*[Mm]arshal" --type go

ctx_test.go (2)

3619-3679: Consider expanding test coverage for CBOR encoding

The test cases look good but could be enhanced for more thorough coverage:

1. Add test cases for complex nested structures and arrays
2. Add test cases for all primitive types (bool, int8/16/32/64, uint8/16/32/64, float32/64)
3. Add test cases for concurrent encoding to verify thread safety
4. Add test cases for handling nil values in nested structures

Example test case for nested structure:

type NestedStruct struct {
    Name     string
    Age      int
    IsActive bool
    Tags     []string
    Metadata map[string]interface{}
}

data := NestedStruct{
    Name:     "John",
    Age:      30,
    IsActive: true,
    Tags:     []string{"user", "admin"},
    Metadata: map[string]interface{}{
        "lastLogin": time.Now(),
        "visits":    42,
    },
}
err := c.CBOR(data)

---

3681-3702: Consider enhancing benchmark coverage

The benchmark is good but could be expanded to:

1. Add benchmarks for different payload sizes
2. Add benchmarks comparing against JSON encoding
3. Add parallel benchmarks to test concurrent performance
4. Add benchmarks for custom encoder scenarios

func Benchmark_Ctx_CBOR_Parallel(b *testing.B) {
    app := New()
    data := SomeStruct{
        Name: "Grame",
        Age:  20,
    }
    b.RunParallel(func(pb *testing.PB) {
        c := app.AcquireCtx(&fasthttp.RequestCtx{})
        for pb.Next() {
            _ = c.CBOR(data)
        }
    })
}

func Benchmark_Ctx_CBOR_Large(b *testing.B) {
    app := New()
    c := app.AcquireCtx(&fasthttp.RequestCtx{})
    data := generateLargeStruct() // Generate large test data
    b.ReportAllocs()
    b.ResetTimer()
    for n := 0; n < b.N; n++ {
        _ = c.CBOR(data)
    }
}

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Check for potential missing CBOR implementations in related files

# Test 1: Check for files that handle JSON/XML but might be missing CBOR
echo "Files that might need CBOR support:"
rg -l "func.*JSON|func.*XML" | grep -v "app.go"

# Test 2: Specifically check bind/binder files as mentioned in PR comments
echo -e "\nChecking bind/binder files:"
rg -l "JSON|XML" bind/

#!/bin/bash
# Let's analyze the CBOR integration more thoroughly

# Check for CBOR-related code in bind and binder directories
echo "=== Checking CBOR implementations ==="
rg -l "CBOR"

# Check specific binding implementations
echo -e "\n=== Checking binder implementations ==="
fd -t f ".*\\.go$" binder/

# Look for content in bind.go to understand current binding mechanisms
echo -e "\n=== Analyzing bind.go content ==="
rg "func.*Bind|type.*Binder" bind.go -A 5

# Check ctx.go for CBOR-related methods
echo -e "\n=== Checking ctx.go for CBOR methods ==="
rg "func.*CBOR" ctx.go

client/client.go (2)

156-176: Fix method documentation to correctly reference CBOR.

The comments incorrectly reference "xml" instead of "cbor". Please update the documentation:

-// CBORMarshal returns xml marshal function in Core.
+// CBORMarshal returns CBOR marshal function in Core.

-// SetCBORMarshal Set xml encoder.
+// SetCBORMarshal sets the CBOR encoder.

-// CBORUnmarshal returns xml unmarshal function in Core.
+// CBORUnmarshal returns CBOR unmarshal function in Core.

-// SetCBORUnmarshal Set xml decoder.
+// SetCBORUnmarshal sets the CBOR decoder.

---

726-727: Consider enhancing Config struct for CBOR support.

The current implementation allows setting CBOR functions but doesn't provide a way to specify CBOR as the preferred encoding in the Config struct. Consider:

1. Adding a ContentType field to Config to allow specifying the encoding (JSON/XML/CBOR)
2. Updating setConfigToRequest to handle CBOR encoding when specified

This would make CBOR support more accessible in the convenient request methods (Get, Post, etc.).

bind_test.go (1)

1102-1129: Consider using CBOR-specific struct tags

While the benchmark is well-implemented, consider using CBOR-specific struct tags for better clarity and to ensure CBOR-specific features can be utilized if needed in the future.

 type Demo struct {
-    Name string `json:"name"`
+    Name string `cbor:"name" json:"name"`
 }

Configuration used: CodeRabbit UI
Review profile: CHILL

ctx_test.go (1)

3661-3679: Consider enhancing custom encoder test

The custom encoder test is good but could be improved by:

1. Testing error cases from the custom encoder
2. Verifying the encoder is actually called with the expected input
3. Testing with different CBOR data types

t.Run("custom cbor encoder error", func(t *testing.T) {
    app := New(Config{
        CBOREncoder: func(_ any) ([]byte, error) {
            return nil, errors.New("custom error")
        },
    })
    c := app.AcquireCtx(&fasthttp.RequestCtx{})
    err := c.CBOR(Map{"Name": "Test"})
    require.Error(t, err)
    require.Equal(t, "custom error", err.Error())
})

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify CBOR MIME type constant definition
# Check for MIMEApplicationCBOR constant
rg -l "MIMEApplicationCBOR.*=.*application/cbor" .

#!/bin/bash
# Let's verify the actual constant definition
rg "MIMEApplicationCBOR.*=.*application/cbor" -A 1 -B 1 ./constants.go

#!/bin/bash
# Description: Verify CBOR binder and decoder implementations
# Check for CBORBinder definition
rg -l "var CBORBinder" binder/
# Check for CBORDecoder configuration
rg -l "CBORDecoder.*interface" config/

#!/bin/bash
# Let's try a broader search for CBOR-related code
echo "=== Searching for CBOR-related files ==="
fd -t f . 

echo -e "\n=== Searching for CBOR-related code ==="
rg -i "cbor" 

echo -e "\n=== Checking config package location ==="
fd -t f "config\.go"

echo -e "\n=== Checking binder package location ==="
fd -t f "binder\.go"