$state.parent, $state.root, $state.children

[timkindberg]

It may be nice to be able to access the parent, root and children states of any given $state.

[ksperling]

Each state currently is internally wrapped by $stateProvider, and on the wrapper all properties are "canonicalized", as well as providing additional properties. I've gone down this path so that state objects that get passed into $stateProvider can be left untouched, so that the application can have application-specific stuff on there without getting it trampled on by $stateProvider.

On the wrapper, the following are currently available:

• .parent -- parent state's wrapper (or the implicit root state)
• .locals -- resolved dependencies if the state is active (this has child objects 'globals', and one for each view)
• .urlMatcher -- I'm thinking of renaming this to 'url' though (so that the url can be directly specified as either a string or an UrlMatcher-compatible object)
• navigable -- the closest ancestor of the state that has a URL (can be the state itself)

One question is how much of this we want to document as a public API, because we're then obviously tied to it to a degree.

'children' isn't currently available but easy to add -- I was considering adding this already as I thought it might come in handy to generate navigation UI that way.

As implemented at the moment, $state.current is the (un-augmented / raw) state that was passed into $stateProvider.state(), and $state.$current provides access to the wrapper.

I'm also thinking of adding $state.states and $states.$states to access all states -- not sure if they should be arrays or objects indexed by state name though.

It's a bit hard to predict which of these things will be most useful -- this is probably an issue where we need to wait for some real-world use.

[timkindberg]

Agreed on real world use. Also you've just graced us with some more valuable explanations.

I like the wrapper. I'm confused about some things.

• Is the injected $state a single state or is it a manager of all the states?
  • $state.current is what confuses me. Why isn't just $state alone the current state? Like when I inject $scope its a single scope, is this how $state works? From the sample project, it does't seem that way.
  • I see things like $state.current == "whatever" and $state.includes("/about"), can you explain. Man we need some docs :)
• things like $state.$current, are those meant to be private APIs? or is $state.current the private one? or are the both public but with different names? I feel like $state.current and $state.current.raw make more sense to me personally, but as you can see I'm very confused, so I probably am suggesting something dumb.

[ksperling]

$state is the service, in the same way that in current Angular $route is the routing service, and $route.current is the current route

With $current vs current, currently the '$' prefixed names are wrapped, and the non-prefixed are the raw objects as passed in (I guess I was thinking along the lines of $ meaning wrapped as in jQuery wrapping DOM nodes...) It also happens to fit with the $-prefixed one maybe being considered private-ish.

$state.$current.self is the same as $state.current (I've called the property 'self', but I guess 'raw' would work as well).

The reason I wanted $state.current to be the raw state is that if in your app you end up putting application-specific stuff on your state object, you don't want that to be accidentally hidden by some undocumented internals of $stateProvider, so I was thinking that for most "normal" use cases you'd just use $state.current.

If using the pattern where you identify states by named variables (var contacts = {} ... $stateProvider.state(contacts)), stuff like if ($state.current === contacts) will also work as expected

[ksperling]

The other reason $state can't be the current state directly is that you can't change the identify of an object once it's been provided via $injector, because it's already been handed out to all the code that uses it where it's referenced via local variables. So $state necessarily always remains the same object. The properties of $state can change at runtime of course.

This is also why $routeParams / $stateParams are a bit icky; it doesn't just get re-assigned to be a new parameters object, the parameters actually have to get copied into it (and any previous properties cleared out).

[timkindberg]

So just curious, when you inject $scope into various controllers, are they all sharing the same $scope object? #angular101

[ksperling]

No, there is a tree of them: http://docs.angularjs.org/guide/scope

[nateabele]

@timkindberg These notes should probably be added to the docs somewhere... Also, do you think we can close this now?

[laurelnaiad]

If you want to borrow any code to access a state hierarchy, I've implemented it by converting states{} to an editable StatesTree. (This is what I was hoping to do in ui-router, and still hope someday to merge in ). http://github.com/afterglowtech/angular-detour . It's not finished (for instance, it doesn't yet expose the States Tree to the service, but the code is pretty much there to contruct/search the tree and edit it. Could be a basis for being able to infer a small portion of a navigational UI as @ksperling mentioned.

[nateabele]

Yeah, having a way to manipulate the state tree ex post facto would be nice, or at a minimum, having an accessor for it. However, I think the big concern is committing to a bigger public API, especially this early on when we've only had a little real-world experience/usage.

[timkindberg]

@stu-salsbury I love how much you are hacking on ui-router. I imagine that you'll be adding some very important chunks of code to the codebase in due time. You seem to be working on some big concepts, so I commend you. Keep going! If you want to join the ui-router team let us know.

Ultimately I think if we think of this project as eventually being incorporated into core angular, we'll want to make sure its easy to use and understand. So if we do add things like state trees, they just need to have APIs that have the complexity abstracted away and the usefulness needs to be readily apparent.

[nateabele]

Yeah, exactly what @timkindberg said. I applaud the effort as well, I'm just trying to tread carefully on how the project evolves in the early stages, especially until we can scale the bulk of the development & review beyond @ksperling (who has done a great job, don't get me wrong, but no one should be a bottleneck). :-)

[timkindberg]

@nateabele I agree

[timkindberg]

@stu-salsbury Oh cut it out! I think you are reading us (at least me) incorrectly, or I'm doing a horrible job of conveying my thoughts. You've not been warned off in the slightest (I thought I just commended you in fact, I wasn't just blowing smoke up your shorts!).

I think your point about state tree is valid and maybe it SHOULD go on the table in a little while. I think you are just moving very fast and alas we are moving very slooooow. My unsure-ness (is that a word?) really stems from not fully understanding where this project is even going. That is something we are working on.

I personally feel that you've added a lot of value to many recent discussions. And I feel that the work you are doing on your own will indeed pay off down the line for ui-router. As of now though, its all unclear. I'm not sure why the team has been a bit unwelcoming, I think its just us questioning every little thing. Have you seen our original discussion?! #8. It's a lot of arguing, but its just because we are trying to all come to a compromise.