Wildcard matching option for query string parameters

[paullryan]

This is a wildcard matching change so that /path/:to/:foo?* is an acceptable url from the UrlMatcherFactory. If given this will match all query string parameters and pass that down to the state. This will also by default cause a reload. You can set the option in your state for reloadWild: false to disable the auto reload based on changes here.

Please feel free to comment about what else you might like to see here as this meets my needs but I'm not sure it meets all needs that I've seen moving back and forth on this issues list. I'd be happy to update this for those needs or give someone else collaborator access to this branch if needed.

[paullryan]

This issue address a good portion of #84 but I don't believe it covers the original intent so I've added it as a separate issue.

[designbyadrian]

I definitely need this! I need my router to be able to take any set of url parameters.

[timkindberg]

I'm wondering if we even need this. Would it be better to just always let any amount of parameters be passed to any state and add them to $stateParams? What is the real benefit of specifying either specific (e.g. url: '/my/route?param1&param2') or wildcard (e.g. url: '/my/route?*') as a parameter on the state url?

Would it be nice to just leave off parameters in the url definition and still be able to pass in whatever params you want:

.state('contacts.detail', {
    url: '/contacts/:id',
    controller: function($stateParams){
        expect($stateParams).toBe({ id:1, paramA: "hello", paramB: "world!" });    
    }
})

<a href="/contacts/1?paramA=hello&paramB=world!">Go to Contact 1</a>

The only reason I can think that it would be good to specify params in the definition is to make supplied params required, but still allow extra params to be passed; or allow you to specify object type like url: "/home?id:Number"

[laurelnaiad]

+1000 for arbitrary url parameters!

[ksperling]

The problem with passing all parameters to every state is how to figure out which states need to be reloaded when any parameter changes, especially when the state that's interested in those parameters has child states.

[christopherthielen]

going through old PRs...
@nateabele will dynamic params supersede this PR?

[nateabele]

@christopherthielen Nah, wildcards are a separate thing. It's still on my radar, just not super urgent. The stuff in the new $stateParams service should make it significantly easier to implement though.

[frogomatic]

Arbitrary query parameters is a big deal in our app which utilizes backend search faceting. It's not feasible to register the parameters on the frontend since they can change at runtime. Is there any movement on this or a workaround?

[cheahkhing]

Hi, i also needed this changes for my requirement of having dynamic query parameters being passed in the url. Is this going to be merged into master? When will i get this in the release?

[wallzero]

Please implement this. It would be very useful to my project. For now my only option is hardcoding field names which are defined in the backend.

[nathanredblur]

When will be this ready?

[nateabele]

@nathanredblur No one is working on it right now.

[frogomatic]

I wound up patching our local version. With the patch you can use
QUERYPARAMS in a state definition e.g.

$stateProvider.state('mystate', { url: '/app/something/:query?QUERYPARAMS',
... });

This will set the QUERYPARAMS parameter to the JSON encoded query
parameters. Any other defined parameters are also set.

You can also do a

$state.go('mystate', {query: 'something', QUERYPARAMS:
JSON.stringify(myQueryParamsHash)});

to trigger a state change.

It's a kludge, but it works for our needs.

Patch is attached. I'm not sure how well github handles attachments, so if
you don't get it, let me know. The patch applies cleanly to 0.2.14 and
0.2.15.

On Tue, Sep 15, 2015 at 12:59 PM, Nate Abele [email protected]
wrote:

@nathanredblur https://github.com/nathanredblur No one is working on it
right now.

—
Reply to this email directly or view it on GitHub
#115 (comment).

[robwalkerco]

@frogomatic I don't think the patch is available from the attachment. Please could you make it available another way? Do you have a fork?

[frogomatic]

Yes, I have a fork: https://github.com/frogomatic/ui-router

The 'master' branch contains the QUERYPARAMS workaround. I applied the
patch to angular-ui-router.js, and manually to the source files, but not to
the minified js file.

There's also a 1119-workaround branch which contains a partial workaround
for the double-encoding of slashes in state parameters (issues 1119 / 1645)

On Thu, Sep 17, 2015 at 5:55 PM, Rob Walker [email protected]
wrote:

@frogomatic https://github.com/frogomatic I donk think the patch is
available from the attachment. Please could you make it available another
way? Do you have a fork?

—
Reply to this email directly or view it on GitHub
#115 (comment).

[kindy]

A) add $stateSearch & $stateHash instead of change $stateParams

B) allow update state's params dynamic.
then we can get real search params in resolver, and trigger $urlRoute.sync() manually to get state's real $stateParams .

As I see, this state.updateSearchParam need to update state.url, state.OwnParams & state.Params.
currently UrlMatcher dose not support update. and the contact not work for this case.

[paullryan]

I know I've let this languish as the core team seemed a little against my initial attempt. If they have a suggestion for pushing this forward such as pulling in the changes from @kindy I'd be happy to help move this issue along. Any thoughts from the core team?

[christopherthielen]

I think we're OK with the wildcard query parameter as a general idea. However, internal parameter handling has had a major overhaul in 1.0, and will continue to change until 1.0 final is reached. This PR will not be compatible with that branch, and parameters in that branch are a bit of a moving target at this time.

Before we'll accept a wildcard PR, we need to address the original caveat raised by ksperling back in 2013. In order to determine which states in the toPath (if any) we should "keep" or we should "reload", we must associate the raw parameters with the states they belong to, and then compare the values.

We need to ensure that the wildcard query param does not interfere with mapping params to path parameters, and does not interfere with mapping query parameters to parent states, as well as to potential substates.

This may be challenging, because the parameters which are associated with a state are statically computed as discrete Param objects.

Here are some relevant lines:

ui-router/src/path/node.ts

Lines 23 to 26 in f8e5f67

	this.schema = state.parameters({ inherit: false });
	const getParamVal = (paramDef: Param) => [ paramDef.id, paramDef.value(params[paramDef.id]) ];
	this.values = this.schema.reduce((memo, pDef) => applyPairs(memo, getParamVal(pDef)), {});

ui-router/src/path/node.ts

Lines 40 to 41 in f8e5f67

	const paramValsEq = key => this.parameter(key).type.equals(this.values[key], node.values[key]);
	return this.state === node.state && keys.map(paramValsEq).reduce(allTrueR, true);

[ergo]

Any update on this? I have a search system that accepts arbitrary "tag names" as params so I cant specify all params upfront in the urls.

[peterjhart]

BTW if you want to access query params you can still inject $location and grab them through $location.search().

[ergo]

@peterjhart, Yes, but the problem is if you don't specify param names in url - the state is not being reloaded. And if memory serves me right, also ui-sref will ignore additional params when generating urls.

[peterjhart]

@ergo ohisee. D'oh.

[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.