🚀 FEATURE: add queries function

[dozheiny]

This PR adds a new function called Queries() to the Ctx struct. This function returns a map of query parameters and their values.

[gaby]

Thoughts

[gaby]

LGTM

[efectn]

Can you add benchmark

[dozheiny]

Sure, I'll add it

[ReneWerner87]

the body of the method still needs to be corrected
encoded strings should not be taken into account, because the control characters are therefore invalid

[dozheiny]

the body of the method still needs to be corrected encoded strings should not be taken into account, because the control characters are therefore invalid

Sure.

[ghost]

This is more of a question to @ReneWerner87 I suppose: but why not use c.app.getString here? Is there a specific reason? It is way slower than using c.app.getString.

I ran a benchmark with string(...) and c.app.getString both 100 times, and the results are these:

with string(...) it takes an average of 1,006 ns/op, uses 418 B/op, and 11 allocs/op _{See Queries.xlsx}

with c.app.getString it takes an average of 725 ns/op, uses 336 B/op, and 2 allocs/op
_{See QueriesPreAllocOpt.xlsx}

This (string(...)) is also in GetReqHeaders, and GetRespHeaders, no other occurance of string(...) in ctx.go, and tests seem to pass just fine with c.app.getString as well, so is there a specific reason that string(...) was used there?

[dozheiny]

@leonklingele I revert two suggestion commits because Linter gets an error.

[ghost]

I revert two suggestion commits because Linter gets an error.

Linter failed because of timeout, not because of the code.
https://github.com/gofiber/fiber/actions/runs/5164476070/jobs/9303393316#step:4:25
https://github.com/gofiber/fiber/actions/runs/5164478717/jobs/9303397503#step:4:25

[dozheiny]

I revert two suggestion commits because Linter gets an error.

Linter failed because of timeout, not because of the code. https://github.com/gofiber/fiber/actions/runs/5164476070/jobs/9303393316#step:4:25 https://github.com/gofiber/fiber/actions/runs/5164478717/jobs/9303397503#step:4:25

Good to know; thanks!

[ReneWerner87]

1. should we split the depth structures and overtake some functions from here
   

   fiber/ctx.go

   Lines 1133 to 1141 in c955d76

   	if strings.Contains(k, "[") {
   	k, err = parseParamSquareBrackets(k)
   	}
   	if strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, k) {
   	values := strings.Split(v, ",")
   	for i := 0; i < len(values); i++ {
   	data[k] = append(data[k], values[i])
   	}

2. why did you revert the performance optimization with the app.getString function?

[dozheiny]

1. should we split the depth structures and overtake some functions from here
   

   fiber/ctx.go

   Lines 1133 to 1141 in c955d76

   	if strings.Contains(k, "[") {
   	k, err = parseParamSquareBrackets(k)
   	}
   	if strings.Contains(v, ",") && equalFieldType(out, reflect.Slice, k) {
   	values := strings.Split(v, ",")
   	for i := 0; i < len(values); i++ {
   	data[k] = append(data[k], values[i])
   	}

2. why did you revert the performance optimization with the app.getString function?

As for your first question, I don't think it's needed.
And for the second question, I'm sorry! I commit this again.

[ReneWerner87]

We should think about the first point, because if we release it first, a change would be a breaking change.

I assume that the users also assume that the array values are split and stored in a deep structure, because otherwise you would have to do it yourself.
With the queryparser many also assumed this

[dozheiny]

We should think about the first point, because if we release it first, a change would be a breaking change.

I assume that the users also assume that the array values are split and stored in a deep structure, because otherwise you would have to do it yourself. With the queryparser many also assumed this

You are right, but the output of this function is a map[string]string.
If we want to survey the array values of the queries, it replaces them with the latest value.
Like this:

c.Request().URI().SetQueryString("list=1,2,3")
queries := c.Queries()
queries["list"] // 3

Do you have any suggestions about the output of the queries function?

[ReneWerner87]

would not ignore any values as no one expects this
we should then change the type of the map and parse infinitely deep

@gaby @efectn what do you think?

[efectn]

Returning map[string][]string seems better to me

[ReneWerner87]

Or map[string]interface{}

[dozheiny]

Or map[string]interface{}

If that map[string]interface{}, a user should convert it into a string or array of series.
Returning map[string][]string makes more sense.

[ReneWerner87]

And what happens for these examples?

GET /api/posts?filters.author.name=John&filters.category.name=Technology

GET /api/orders?filters[customer][name]=Alice&filters[status]=pending

[ReneWerner87]

Some more interesting examples which we should consider

GET /api/search?filters[category]=electronics&filters[tags][]=apple&filters[tags][]=orange&filters[tags][]=banana

GET /api/search?tags=apple,orange,banana

GET /api/search?filters[tags]=apple,orange,banana&filters[category][name]=fruits

GET /api/search?filters.tags=apple,orange,banana&filters.category.name=fruits

GET /api/search?filters.tags.0=apple&filters.tags.1=orange&filters.tags.2=banana&filters.category.name=fruits

GET /api/search?filters[tags][0]=apple&filters[tags][1]=orange&filters[tags][2]=banana&filters[category][name]=fruits

Can you include these examples in the test and document the expectations

[dozheiny]

Sure, I add this test case and documents.

[dozheiny]

@ReneWerner87 shouldn't we make output of function to map[string][]string?
I'm just asking because you approve PR.

[ReneWerner87]

Not really, I thought about it again and thought that it is ok, as long as we describe it well in the documentation.
Then you get exactly, the key value pairs which are to be recognized also in the query url, without any postprocessing