Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$stateParams not populated when resolving dependencies for nested views #31

Closed
robschley opened this issue Feb 19, 2013 · 7 comments
Closed

Comments

@robschley
Copy link

I've been experimenting with the new routing code and I've managed to get pretty far in converting an existing application to use the new code but I've run into a bit of a problem and I'm not sure if it is because I am doing something wrong or if it is a bug.

The issue is that $stateParams nor anything that I can see in $state has the URL parameters for the view that is being transitioned to when attempting to resolve a nested view. You can see this issue in the example application and I created a branch that demonstrates it here: https://github.com/robschley/router/blob/stateParams/sample/index.html#L115

The contacts.detail view defines dependencies to resolve before initializing the controller. To effectively resolve those dependencies, one would expect that $stateParams or $state would provide the URL parameters for the view that is being transitioned to. In this case, contactId should be available in $stateParams. When resolving "something" in the sample, there seems to be no way to get to the contactId because it is not populated into $stateParams until AFTER all of the dependencies have been resolved.

Is this a bug or am I doing it wrong? Any guidance is much appreciated.

@timkindberg
Copy link
Contributor

Probably a bug, @ksperling may have to look at it (he just had a kid). It does make sense that $stateParams would be available in resolve.

@timkindberg
Copy link
Contributor

Actually, did some research on this. In the current $route service in angular, $routeParams is not ready yet in resolve either. So it may be a technical limitation that we can't get around, we will look into though.

Check out this video: http://www.youtube.com/watch?v=P6KITGRQujQ, right around 3:45 he says it...

@timkindberg
Copy link
Contributor

Sorry should have also mentioned that you should be able to use $state.$current.params in resolve instead, let me know.

@ksperling
Copy link
Contributor

Hm, its meant to work like that... $stateParams should be part of the 'locals' passed to $injector when any calls related to 'resolve' or onEnter are made. Ill look at it when I get a chance.

What currently doesn't work and isn't meant to work is injecting $stateParams into a service and using that during resolve... it seems that kind of usage would be bound to have unintended or at least unintuitive results in some use cases no matter when the global $stateParams get written, so it seems best to discourage (or even disallow?) such usage.

Rob Schley notifications@github.com wrote:

I've been experimenting with the new routing code and I've managed to get pretty far in converting an existing application to use the new code but I've run into a bit of a problem and I'm not sure if it is because I am doing something wrong or if it is a bug.

The issue is that $stateParams nor anything that I can see in $state has the URL parameters for the view that is being transitioned to when attempting to resolve a nested view. You can see this issue in the example application and I created a branch that demonstrates it here: https://github.com/robschley/router/blob/stateParams/sample/index.html#L115

The contacts.detail view defines dependencies to resolve before initializing the controller. To effectively resolve those dependencies, one would expect that $stateParams or $state would provide the URL parameters for the view that is being transitioned to. In this case, contactId should be available in $stateParams. When resolving "something" in the sample, there seems to be no way to get to the contactId because it is not populated into $stateParams until AFTER all of the dependencies have been resolved.

Is this a bug or am I doing it wrong? Any guidance is much appreciated.


Reply to this email directly or view it on GitHub:
https://github.com/angular-ui/router/issues/31

@robschley
Copy link
Author

@timkindberg Unfortunately, $state.$current.params does not contain the parameters either. I dug into $state and $state.$current quite a bit but wasn't able to find anything with the parameters for the transitioning to view.

The code that I am converting originally used $route.$current.params.

@juanpujol
Copy link

Sorry to open this again, but I'm trying to get $stateParams inside a factory that I'll resolve and it just returns an empty object. What's funny is that if I do console.log($state) on the Service resolving I can see the content of $state.params witch is { id: "123" } but if I try to console.log($state.params) it returns empty object. This's very frustrating =S.

Anyone can help me?

Thanks.

@ksperling
Copy link
Contributor

$stateParams is special in that if you get it injected globally, it will only contain the parameters for the current state once the transition into that state is complete.

To access the parameters of the state being transitioned to, you have to get $stateParams injected by 'resolve' or the state onEnter event, because $stateParams is special-cased in those injections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants