The params option in state configurations doesn't handle well deep objects

[tbassetto]

I may be using the params options when configuring a state for an unexpected scenario.

I have a login page defined like this:

$stateProvider.state('login', {
    controller: 'LoginCtrl',
    templateUrl: '/scripts/core/login.html',
    url: '/login',
    params: {
        goToNextState: null,
        goToNextParams: null,
        reason: null
    }
});

I used params because I want to pass information to the login page (like why someone would end up being redirected to that page and where to go next once successfully logged in) without "polluting" the URL.

If an auth error happen I used the following code:

$rootScope.$on('$stateChangeError', function (event, toState, toParams, fromState, fromParams, error) {
    if (error.type === 'auth') {
        $state.go('login', {
            goToNextState: toState.name,
            goToNextParams: toParams,
            reason: 'Auth error yadda yadda'
        });
    }
    // ...
}

With ui-router 0.2.12 I see two issues:

1. The params appears in the URL as query strings, I was expecting them to be invisible. Can I "fix" that?
2. In LoginCtrl, $stateParams.toParams equals the string "[object Object]" instead of being the toParams object from before. Is that an expected behavior or a bug?

[christopherthielen]

Sounds like a bug. Can you put this in a plunk?

[tbassetto]

Here is a minimal testcase for the bug where my "complex" $stateParams will be encoded into a string: http://plnkr.co/edit/lwMGRoyJJkJLu5bXohYD?p=preview

Obviously this bug will mostly happen to people using the params state option, not when using classic URL paths as params (/something/:id) because those are usually primitive type (string, number, etc.).

Still I am not sure if params that aren't URL paths should appear as query string? Is it expected or another bug if I end up having URLs like /login?goToNextState=...&goToNextParams=...?

[christopherthielen]

Is the following behavior what you would expect? I added an "any" type for parameters which don't encode or decode, it just passes the value. I made this the default type for "config" parameters, i.e., non-url parameters.

I'm going to have to dig in a little deeper to figure out why your params showed up as a query parameter. That was quite unexpected. Somehow changing to "any" type seems to have resolved that.

http://plnkr.co/edit/iaSEIor4BV3zq6HpXdLN?p=preview

[tbassetto]

Yes, this behaviour looks correct, thanks.

Just to make it clearer, I forked your plunk to add urls-parameters to the protected page (I should have done that in the first place), so that gotToNextParams is not just an empty JavaScript object: http://plnkr.co/edit/f3nxsr8TcRrDL3AIZ2S6?p=preview

[tbassetto]

From what I can see, the fact that params options show up as a query parameter is not happening with the version 0.2.11 but is with 0.2.12.

[christopherthielen]

should be fixed today