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
In the old router, the new router and the very new router querystring parameters always are accessible as {[k:string]:string}. To pass an array of values via the querystring we have to rely on encoding within the application to serialize and then deserialize the array. We should be able to simply rely on existing URL standard behavior.
When retrieving data parsed from a querystring it should be presented either in a datastructure that supports the standard or in a class that models it properly.
My suggestion would be to model the query params as {[k:string]: string | string[]}
Then you can do
var params = new URLSearchParams()
params.set('foo': 'bar');
and
params.set('foo': ['bar','qux']);
background material:
The RFC for URI - https://tools.ietf.org/html/rfc3986#section-3.4 certainly does not say that query parameters cannot be repeated. There is sentence which says that query parameters are 'often' key/value pairs, but there definitely no restriction on the number of times a parameter can be specified.
Coming from a Java background - JAX-RS (jsr 311) lets you specify a query parameter of type List or of List if you implement methods for converting from String to T. https://jsr311.java.net/nonav/releases/1.1/javax/ws/rs/QueryParam.html
(as opposed to rails, php & co which seem inclined to use the foo[]=bar syntax)
From @xealot on June 10, 2016 16:3
Note: This is a copy of my issue from, #9138.
I don't know which is the appropriate location.
I'm submitting a ...
Current behavior
In the old router, the new router and the very new router querystring parameters always are accessible as
{[k:string]:string}
. To pass an array of values via the querystring we have to rely on encoding within the application to serialize and then deserialize the array. We should be able to simply rely on existing URL standard behavior.Adding to my frustration, there is already a class,
URLSearchParams
that fully models the querystring but seems unused when retrieving url search params from the router.https://angular.io/docs/ts/latest/api/http/URLSearchParams-class.html
Expected/desired behavior
When retrieving data parsed from a querystring it should be presented either in a datastructure that supports the standard or in a class that models it properly.
My vote is for the URLSearchParams version of course.
Copied from original issue: angular/vladivostok#35
The text was updated successfully, but these errors were encountered: