-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Comments
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. |
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... |
Sorry should have also mentioned that you should be able to use $state.$current.params in resolve instead, let me know. |
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:
|
@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. |
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. |
$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. |
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.
The text was updated successfully, but these errors were encountered: