You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Passing query parameters with keys that aren't snake_case in url_for is currently not possible, as python only allows underscores in function parameter names. However it is quite common for query parameters to be hyphenated. So for example, generating a url like http://server/posts/5?user-id=123 is currently not possible with url_for. Someone may even want to use camelCase for their parameter names.
Describe the solution you'd like
It would be nice if there were an additional parameter like hyphenate: bool = False or something that would do something like {k.replace('_', '-'): v for k, v in kwargs.items()} before encoding query parameters, as it is extremely common to separate query parameters with hyphens instead of underscores.
Or better yet, have an additional parameter query_params: Dict[str, Any] that accepts a dictionary of str: any pairs, and adds that as query parameters, which would also allow passing camelCase parameters (personally don't need this, but someone might), and just update the current kwargs with it
Additional context
The codebase I'm currently working on uses hyphens for query parameters, so either the entire codebase would need to be reworked, or I'd need to manually manipulate the string from url_for and add hyphenated query parameters to make things work as expected. Creating a built in option for handling this would be very helpful. The current functionality of implementing anything that is not a request parameter as a part of the query string should not be removed for backwards compatibility, but adding a query_params parameter would also serve the purpose of self documenting code more clearly
The text was updated successfully, but these errors were encountered:
Always converting underscores to hyphens seems the most reasonable, although noting that this cannot be done with url_for without breaking compatibility. It's been long proposed to introduce another method of constructing URLs (by @ahopkins) and making it anew would allow addressing not just this but also any other problems.
Adding another toggle in kwarg or global (app/blueprint) setting for compatibility is something I am not too fond of.
both proposed additions would not break compatibility. But yeah, I've seen Adam mention on Discord that url_for is on his radar for a complete overhaul, so ig there's nothing to be done about it until then
Is there an existing issue for this?
Is your feature request related to a problem? Please describe.
Passing query parameters with keys that aren't snake_case in
url_for
is currently not possible, as python only allows underscores in function parameter names. However it is quite common for query parameters to be hyphenated. So for example, generating a url likehttp://server/posts/5?user-id=123
is currently not possible withurl_for
. Someone may even want to use camelCase for their parameter names.Describe the solution you'd like
It would be nice if there were an additional parameter like
hyphenate: bool = False
or something that would do something like {k.replace('_', '-'): v for k, v in kwargs.items()} before encoding query parameters, as it is extremely common to separate query parameters with hyphens instead of underscores.Or better yet, have an additional parameter
query_params: Dict[str, Any]
that accepts a dictionary ofstr: any
pairs, and adds that as query parameters, which would also allow passing camelCase parameters (personally don't need this, but someone might), and just update the current kwargs with itAdditional context
The codebase I'm currently working on uses hyphens for query parameters, so either the entire codebase would need to be reworked, or I'd need to manually manipulate the string from
url_for
and add hyphenated query parameters to make things work as expected. Creating a built in option for handling this would be very helpful. The current functionality of implementing anything that is not a request parameter as a part of the query string should not be removed for backwards compatibility, but adding aquery_params
parameter would also serve the purpose of self documenting code more clearlyThe text was updated successfully, but these errors were encountered: