Retrieving a state by name

[DylanArnold]

Hello,

I'm looking at adding a permissions system to my app and I am looking at attaching some data to a state which defines the permissions a user must have in order to access a state.

Example definition:

$stateProvider.state('admin', {
    url: '/admin/:id',
    templateUrl: '/admin.html',
    controller: 'AdminCtrl',
    data: {
        auth: ['Staff', 'Admin'] // Could be a callback which is passed the state params
    }
});

This data could be a set of roles which a user is required to have before they can access the state, or it could potentially contain a callback which would ideally have access to the parameters passed to a state to determine access to a state on a more fine grained (parameter determined) level.

This seems like it will work fine to restrict access to certain states. I can write a $stateChangeStart authorization plugin which will check the next state, and redirect the user to a login or permission denied page if they don't have access, based on the data I defined on my state.

So far this is all possible. The problem I am trying to figure out is how to only display certain elements on a page such as navigation links based on these same permission tests.

I am thinking of writing a directive that would retrieve a state and run the same permission tests as above, showing or hiding the target element. At first, for the case where I want to show or hide navigation elements, I wanted to retrieve a state given a url, but haven't found a way to do this yet. Then I saw the ui-sref directive, it would make just as much sense to create a directive similar to this, or modify this directive but also retrieve the state by name, run my authorization logic (passing any parameters through), and show or hide the element depending on result.

How can I retrieve a state by name? As far as I can tell, there are no accessors for this. Is there another way to accomplish this?

Thanks for your time.

TLDR
How do I retrieve a state by name?

[timkindberg]

There's in internal method in the $state provider, findState(), but there is no way to find a state externally. You'd have to alter the code and do a custom build, or we'd have to add this feature.

@ksperling would this be a dangerous feature to add, would it promote more anti-patterns? I'm not sure why but it sounds like a bad thing to allow. Then people could alter states on the fly, and who knows what would happen...

[DylanArnold]

My first thought in reponse to that was, hang on, isn't the state exposed in $stateChangeStart()?

After a little bit more inspection it appears as though in registerState() the original object is wrapped in the self property of an internal object to manage some private data https://github.com/angular-ui/ui-router/blob/master/src/state.js#L22

I'm assuming for the public interface, there shouldn't be a need to access the internal object, but if the stored self object is considered public then retrieving a state by name should return that. As an end consumer I shouldn't ever need to know about the internal representation or be exposed to it.
I may be wrong but from what I can tell you can think of a state in terms of the public interface, the object passed to $stateProvider.state(), and the private state, retrieved by findState() which I should never need to know about.

It appears this is the case for $stateChangeStart(). As you can see here https://github.com/angular-ui/ui-router/blob/master/src/state.js#L195 it returns the .self object.

[braco]

So how can you check if a state exists? Even an array of available state names would be helpful.

It would be handy for something like this:

$rootScope.$on('$stateChangeStart', function(evt, toState, toParams, fromState, fromParams) {

var testFor = toState.name + "loggedin";

if (user.loggedIn === true && STATE_EXISTS(testFor)) { 
//  transitionTo(testFor)
}

})

Allowing special case states to be used (that may or may not exist)

[eahutchins]

This seems like a basic feature required for lazy loading states, why was the issue closed? Introspecting the current state graph would be useful for writing general purpose debugging code as well.

[laurelnaiad]

You can't lazy load states in ui-router. If you're a good coder and don't mind getting your hands dirty, you're welcome to pick up where I've temporarily left off with angular-detour. Drop me a line in an issue there if you want to use it and can't figure out how.

Keep in mind that you need an active server to lazy load states from the server based on URLs or state names.

If you just want to modify/add/delete state definitions on the fly at runtime in angular, that's very straightforward in detour.

Its biggest drawback at the moment is that it's about 1 month and a half behind the commits to ui-rotuer.

[laurelnaiad]

For those who, as the OP wanted, just want to find out about your states, define them in a hash object (with any extra bells and whistles that you will want at runtime) outside of calls to .state... then just iterate over your object to call .state to define the routing and hang onto your custom state definitions when you need to know something about them.

[eahutchins]

I've implemented the lazy-loading part using our own back-end secret sauce, and I've been cribbing from the work you and others have done for how what I've loaded gets patched into ui-router/angular. I can obviously build my own cache of which states have already been lazy-loaded, but it seems like a generally useful feature for ui-router to support (and some of the ideas for a debugging tools that I'm thinking about would benefit from going to the canonical source of truth about what the currently loaded state graph looks like).

[laurelnaiad]

Sounds like you just want to patch ui-router if all you need is to make findState public. If you do that and exposes the .state function in the service, you've got the underpinnings of a busy/poor man's lazy load-able version.

[DylanArnold]

So far I haven't seen any arguments against this feature, it seems like a no brainer to me.

Yeah I ended up writing my own service to wrap $stateProvider.state and hold references to each state. It's a bit of a hack but it works and seems less hackish than patching the source.

I was thinking about submitting a pull request but I'd prefer to know if it's just going to get rejected.

[DylanArnold]

By the way it isn't findState that needs to be exposed, it is the reference to the object stored in self which is considered public anyway.

[laurelnaiad]

Search closed issues you may find some arguments against. I never wanted to "take a detour" but lazy and runtime changes werent considered a priority and/or too complicated.

[DylanArnold]

I feel like you haven't read my issue very thoroughly. I at least wasn't asking for runtime changes. This is a very simple issue, and the object I mention is already exposed in $stateChangeStart or you can keep a reference by yourself, so I don't yet see how this could be a problem.

[laurelnaiad]

I don't mean to dissuade you. I thought you were talking about lazy
loading states, which I interpreted to mean changes to states at run-time.

On Thu, Jul 25, 2013 at 3:29 PM, DylanArnold notifications@github.comwrote:

I feel like you haven't read my issue very thoroughly. I at least wasn't
asking for runtime changes. This is a very simple issue, and the object I
mention is already exposed in $stateChangeStart or you can keep a
reference by yourself, so I don't yet see how this could be a problem.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/265#issuecomment-21589481
.

[timkindberg]

The reason it was closed—certainly not with an iron fist and the issue could be reopened—is because accessing the state config objects at run time may give the incorrect impression that those config objects can be altered at any time. We have not yet fully determined if we want to allow runtime editing of state properties, we have decided "no" for now, certainly until we've reached a stable code base with the current feature set.

If there was some way to ensure that the state map was read only and devs knew it, I would be open to reopening this feat request.

@nateabele what do you think, am I wrong in my assumption?