Match any and all query parameters in ui-router state

[npm622]

Apologies in advance if a GitHub issue is not the proper forum for this question -- I raised a StackOverflow question a few days back and have received zero responses, so I thought I'd turn here.

I am using UI-Router 1.x. It seems that dynamic parameters are nearly what I'm looking for, however, I do not know the names of the parameters I should be expecting, so I cannot explicitly list them and provide defaults (as dynamic parameters need).

The gist of it is, I'd like the following URLS all to route to the same component:

• #/.../update?id
• #/.../update?username
• #/.../update?customerId&sandwichId

The routed component has an $onInit method that, along with a provided service, has enough information to parse whatever query parameters happen to be there. However, I cannot get the state to be activated without specifying each and every potential name of query parameter that could come through. These query parameter names are data driven, so I don't even have a finite set to do this with.

I have a non-ideal solution currently: I define one query parameter on the state, pkKeys, and then manually construct the entire query parameter string I desire and set that as pkKeys' value. In my routed component's controller, I take on additional pre-step in parsing that entire query string value by splitting on '&' and '='... Obviously it's not great, but it does align with my desired functionality.

I have tried to leverage $location.search() to supply query parameters, but have had no success with this so far.

It feels like I'm just asking for tips here, and I should just wait it out on StackOverflow. But I've spent 3 days now tinkering with the different approaches found in the ui-router guide to no avail. If this is something that just isn't supported, knowing that would at least save me some time here.

Thanks in advance for any help!

-Nick

[christopherthielen]

If this is something that just isn't supported, knowing that would at least save me some time here.

Wildcard search parameters is not currently supported, sorry :(

Supporting them is definitely up for consideration, but not high on the priority list.

[npm622]

Understood, thank you at least for the clarification.

In terms of handling "this issue", I'll defer to you as to what's best here. I'd love to somehow be notified if/when functionality like this does make its way to ui-router, however, I by no means need to this specific issue remain open for something that's not even prioritized yet. Apologies if there's an obvious natural progression of this, I'm new to the open-source game.

[christopherthielen]

I thought we had an additional issue about wildcard query params, but I can't find it.

There is an old (not mergable) PR #115.

[lolsborn]

This would be an awesome feature. Because of the lack of it we're doing some silly stuff like base64 encoding query params and passing them as one single known parameter.

[ergo]

Any news for this? I'm still looking for a solution to support search engine like tag search functionality with ui router - i think I might also resort to base64 encoding, but this is far from ideal.

[loxy]

We also need this feature as we have to sync the url in a portal (parent) / app (iframe) scenario. So the url is divided into two part and we have to communicate the app part to the iframe with the whole query parameters. Is there any other option? Like url: '/**tail'?

[ChidoYo]

I just did the following in order to be able to receive either the query string 'filter' OR 'location' and it works for me. Here's the sample of my code:

.state('classes', {
url: '/classes?{filter}{location}'

I got lucky.
Thoughts?

[christopherthielen]

@ChidoYo that's not supported and provably works by accident. Beware it may change in a future release!

[nsamarak]

+1

[mhinkka]

+1

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.