Addition of Locals Function with Go Generics as an Alternative to c.Locals

[ryanbekhen]

Introduced a new function, Locals, that utilizes Go's generics to handle and retrieve type-specific local values within a request context. This enhancement provides more accurate data type control within the context. Included are tests for generic and custom struct use-cases to ensure the function performs as expected.

Description

This pull request presents an alternative version of the Locals function using Go's generics. This new implementation of Locals function provides enhanced type safety and allows for more specific data type handling within the request context.

Key features of this implementation:

• It utilizes the Go's generics feature allowing it to handle varying data types dynamically. It takes a generic parameter [V any].
• The function tries to convert the input context to a DefaultCtx pointer and will throw an error if this conversion fails.
• The implementation uses the generic V for defining the type of value being retrieved from the context.
• It ensures that the returned value matches the type defined by the generic parameter.

This alternative Locals function provides an optional method for type-specific context manipulation. It brings enhanced type safety and data type specificity to the table which results in more resilient code.

Noteworthy: This code requires at least Go 1.18 for its use of generics.

Changes Introduced

List the new features or adjustments introduced in this pull request. Provide details on benchmarks, documentation updates, changelog entries, and if applicable, the migration guide.

• Benchmarks: Describe any performance benchmarks and improvements related to the changes.
• Documentation Update: Detail the updates made to the documentation and links to the changed files.
• Changelog/What's New: Include a summary of the additions for the upcoming release notes.
• Migration Guide: If necessary, provide a guide or steps for users to migrate their existing code to accommodate these changes.
• API Alignment with Express: Explain how the changes align with the Express API.
• API Longevity: Discuss the steps taken to ensure that the new or updated APIs are consistent and not prone to breaking changes.
• Examples: Provide examples demonstrating the new features or changes in action.

Type of Change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• Enhancement (improvement to existing features and functionality)
• Documentation update (changes to documentation)
• Performance improvement (non-breaking change which improves efficiency)
• Code consistency (non-breaking change which improves code reliability and robustness)

Checklist

Before you submit your pull request, please make sure you meet these requirements:

• Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
• Conducted a self-review of the code and provided comments for complex or critical parts.
• Updated the documentation in the /docs/ directory for Fiber's documentation.
• Added or updated unit tests to validate the effectiveness of the changes or new features.
• Ensured that new and existing unit tests pass locally with the changes.
• Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
• Aimed for optimal performance with minimal allocations in the new code.
• Provided benchmarks for the new code to analyze and improve upon.

Commit Formatting

Please use emojis in commit messages for an easy way to identify the purpose or intention of a commit. Check out the emoji cheatsheet here: CONTRIBUTING.md

[ReneWerner87]

some little adjustements needed

[ryanbekhen]

@ReneWerner87 I've done the push, pls check.

[ryanbekhen]

@ReneWerner87 I've done the push, pls check again.