Get params of a state (config)

[davidpfahler]

I – and I assume others as well – have the use case where I need to get the configuration parameters, in my case the url property, of a state which is not the current state. The idea is that I want to determine whether navigating to a state would be considered navigating "backwards", which I do by comparing the URLs.

I have implemented two versions that would equally work for me and have pros and cons. I tried to address issues mentioned in #265, namely that you don't want to give the impression that you can modify options at runtime. This is why my implementation is only a getter and does return either a primitive or a copy of the object. I wanted to discuss the alternatives and get your opinions before writing tests, docs and sending a pull request.

getOptionOfState(option, stateOrName)

This implementation only returns primitives. The upside is that nobody should expect this to be changable on runtime. The downside is that it's cumbersome if you want all options.

getOptionsOfState(stateOrName)

On the other hand, this is more prone to misunderstanding. It does return a new object using angular.copy, but still might give the impression that you can modify it and it would have an effect.

I prefer the second alternative, because I think we need to make stuff that's not harder to use for smart developers. The "get" in the name of the method is a hint that it's not the same object you are receiving.

We could, of course, also have both methods. What do you think?

[timkindberg]

I'm thinking we just do $stateProvider.state("stateName") to return
that state's config object if only 1 string parameter is passed. In
the docs we'll just mention that its a copy.

[davidpfahler]

Is that feature implemented already?

[nateabele]

@timkindberg Doesn't look that way. Even if we did, that would only help at configuration time.

[davidpfahler]

@nateabele 👍

[timkindberg]

Sorry i wasn't saying we do that already that was just my suggestion. I don't really care though.

[davidpfahler]

@timkindberg For my use case, and I guess for others' ass well, I think it's important that you can get config at any runtime, not just at configuration time (as @nateabele pointed out). Are you in favor or against this kind of change? If the former, what implementation route should we go?

[timkindberg]

@davidpfahler I'm on board. I'd prefer returning the whole object. getStateObject or getStateConfig.

@nateabele I forgot that providers are only meant for config time.