$state.parent, $state.root, $state.children about ui-router

[christopherthielen]

Each state is now decorated with $$state() in ui-router 1.0. $$state() returns the internal StateObject (internal, so API is subject to change)

$state.get('foo').$$state().parent

[YoungLua]

谢谢，就是不太明白哈

[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.

[laurelnaiad]

Thanks, @timkindberg. I'll back off on this for now.

[ksperling]

@nateabele reasons for having $state keep its own stuff on a wrapper and keeping the user-supplied object untouched were

• to be able refer to states by reference rather than by name, so there is some compile time protection against typos
• to allow state objects to have custom data or logic on them. e.g. rather than bags of configuration users are free to e.g. make them instances of a custom class/constructor.

I'm not sure either of these features are much used at the moment though (even though somebody posted some code for custom state.scrollTo logic for example), and maybe a richer runtime API for states would have more value.

[nateabele]

@ksperling Not sure what you were responding to? I'm aware of the reasoning and wasn't questioning it. My comments were mainly regarding an API for traversing and manipulating state hierarchy at runtime.

[ksperling]

I'm just saying we may need to revisit the decision if the use cases for a rich state tree API outweigh those for the 'app owns the state objects' approach.

[nateabele]

Are those use cases necessarily orthogonal to one another?

[SmithSamuelM]

I have a use case for

""" 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. """

When using a navbar or other nvaigation aid it is nice to have a way to highlight the correct tab or element based on the current route or state. The angular $route.routes provided all the existing routes so one could use this generate an object that mapped routes to ui element highlights and then use $route.current to find the right item in the map.

It would be nice to have the same with $states
$state.states
$state.routes since this is not the same as $state.states

also having an api that mimics the Angular one is usually a safe bet for capturing use cases

[laurelnaiad]

I agree (with all my bones) that having access to the state definitions in a tree at runtime is useful. https://github.com/afterglowtech/angular-detour is my way of doing that. It builds a tree for a bunch of reasons, some of whic are way outside the scope of this issue... but among them is being able to query the "state" of the router at runtime and to be able to navigate up and down the tree. I can't recommend you use it now because it's an immature beginning, but it is one way to tackle the challenge that you've presented.

[laurelnaiad]

I really need to stop linking to detour when someone brings up the issues that I tried to tackle. I'm sorry. I don't know quite how to handle it -- do I tell people about it -- do I just stay away from the ui-router issues? Have you guys (ui-router team) looked at it? I don't want to steal thunder and I asked if I could contribute... so it's a branch of sorts even if technically I've just applied the MIT license and made changes to suit my needs.... there's really not that much thunder there to begin with... but sometimes I wonder whether we're all talking about the same things. @jeme how do you do it? Perhaps more importantly, @ksperling how you would like me to be involved (or not). I want to do what's right for ui-router but I"m not sure how to proceed. If you just want me to lay off of github and answers I'm totally fine with that, too. Please tell me what will work for you and I'll do it. I know I owe Nate a test case and I know I can get there soon if it's still applicable. But generally I don't know if I'm helping or hurting when things crop up that I've already tackled in my personalized copy of $state -- and I dont want to step on toes if I refer to it.

[nateabele]

@stu-salsbury When determining the efficacy of any piece of code, more eyes, and more real-world usage is always better. If a few people pick up angular-detour and find it really useful, great, then we have several real-world-experience perspectives on what works in an API and what doesn't.

I think I can speak for everyone when I say that there's no ego here regarding solutions. If there are particular issues you've solved in your own branch, by all means, pimp it. The more people who are using it, the more people there are who can evolve it and contribute to a final, usable solution in ui-router.

[laurelnaiad]

@nateabele I wasn't pimping anything. I'm sorry that it seemed that way. I wanted to participate in ui-router's evolution because it's a great tool. I don't undestand the defensive guards that come up when I ask about how I can avoid proferring a solution that I asked to be included -- that's what was rejeceted.... and that's ok... ui-router is allowed to be ui-router and I'm happy to have found it. In the interest of open source, I wanted to keep some discussions alive about alternatives to the array based way that ui-router stores its states... you and the project can shut me down for asking, but I asked. I tried to do so nicely. I have your response. Please consider it a done deal. No hard feelings.

[ksperling]

@stu-salsbury I've got no problem with you pointing people at angular-detour, if that solves their particular issue. I also don't have anything against you (or anybody else) contributing idea or code back to ui-router itself. The way I read @nateabele 's comment he's got the same view... Maybe you're reading too much into the word "pimping"?

I'm also a strong believer in designing software that is focused and modular, and in a way that decomposes cleanly, and where ideally each piece has one clear responsibility. While ui-router is still very much evolving, I think it's helpful to stick to the "80% of cases need this" features and leave the syntactic sugar or rarely used things for later, so that the overall design is based on the common use cases and doesn't get bogged down too much in the fringe stuff that only benefits a small number of use-cases.

For various reasons I consider dynamically changing state definitions at runtime to be in the fringe category, which is why I didn't want to include it at this time. However that doesn't mean you contributions to the project in general aren't valued.

[laurelnaiad]

@ksperling Thank you for taking the time and energy to share your thoughts/feelings about what I've tried to "pimp" :) even if I wasn't trying to pimp anything. I wanted to know whether I should keep mentioning my methods and for solving some of the challenges that users seem to have, and if I mentioned them, then whether or not it was ok to refer to my code (which is of course based on yours :)

I think I have the answer to that question now. I will stop advocating a tree and I will make sure that I don't pimp anything here....again, please know that I asked how I could refer to it because I wanted to communicate code, not because I want to sell anything.... it is of course all open source software. I hope that if I stepped on your toes or anyone elses, that you'll forgive me. I meant no harm and I appreciate the clarification. If there's confusion about whether I've been advocating that ui-router should support dynamic/runtime configuration, please know that all I really wanted was an event or two to have hooks... and as I think I've made all to clear -- I'd prefer a tree to an array... yadah yadah... but ultimately just please know that I appreciate what you've built and I don't need or want to sell an alternative! Thanks for helping to set the record straight... and just one more time for everyone who has any doubts... I ain't pimpin.. I just wanted to know whether I should communicate my ideas with code, with text, or just keep them to myself when I realize that I'm barking up the wrong "tree"! :)

[laurelnaiad]

When determining the efficacy of any piece of code, more eyes, and more real-world usage is always better. If a few people pick up angular-detour and find it really useful, great, then we have several real-world-experience perspectives on what works in an API and what doesn't.

Gosh I can't resist... @nateabele I really don't care who picks it up. I'm writing it for myself -- and trying to share it for those who might benefit... and if I happen to mention in in the context of ui-router its because I hope that what I'm doing might help someone else along the way....share code, whatever... to talk about it... to make it better... that's what we do, right? Are you trying to tell me about a profit motive that I don't have? Or just that I should stop quoting my software because it doesn't have enough users? Jeeze man... I asked because I wanted to know whether there were lingering issues with me talking about how my adaptation addresses specific user issues -- as in a tree..... obviously there are issues with me talking about it... you've made yourself abundantly clear... so I can at least appreciate that I got an answer to my question, even if I'm left scratching my head about what made you think I was selling something....

[nateabele]

@stu-salsbury Haha... dude, I think we are in violent agreement. :-) This:

I'm writing it for myself -- and trying to share it for those who might benefit... and if I happen to mention in in the context of ui-router its because I hope that what I'm doing might help someone else along the way....share code, whatever... to talk about it... to make it better... that's what we do, right?

...is exactly my point. ;-)

[laurelnaiad]

Ok, cool... not trying to be violent :) ...my intent was to provoke discussion. So since it clearly came out wrong, I apologize for the way it sounded. It was meant in the spirit of sharing.

[coreConvention]

"'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."

Please do, this would be very useful for what I am working on now.

And actually on that note, I have one question: if I get the state using $state.get('statename') it is getting raw object, but how can I resolve the wrapped object whereby I could then call parent? If I could just do that I could do without a "children" property.

[timkindberg]

@VasiDeus It's not currently possible to get at the wrapped state object

[eduardoinnorway]

What is status? Anyone working on it´?

[kentcdodds]

Guessing this issue's pretty much dead? :-(

[christopherthielen]

@kentcdodds I wouldn't say dead, but not high priority. If you want to do this yourself, you need access to the internal state objects, which have .parent on them. Take lines 4-18 of ui-router-extras-core and add them to your project, then you will have a $$state() unwrapper function on each state that comes out of $state.get(). You can then build the tree yourself.

mod_core.config([ '$stateProvider', function ($stateProvider) {
  // Decorate any state attribute in order to get access to the internal state representation.
  $stateProvider.decorator('parent', function (state, parentFn) {
    // Capture each internal UI-Router state representations as opposed to the user-defined state object.
    // The internal state is, e.g., the state returned by $state.$current as opposed to $state.current
    internalStates[state.self.name] = state;
    // Add an accessor for the internal state from the user defined state
    state.self.$$state = function () {
      return internalStates[state.self.name];
    };

    angular.forEach(stateRegisteredCallbacks, function(callback) { callback(state); });
    return parentFn(state);
  });
}]);

$state.get('foo').$$state().parent;
$state.get().forEach(function(state) {
  buildTreeFunctionAddStateToTree(state.$$state());
});

[kentcdodds]

@christopherthielen, understood. Thanks for the code snippet. 👍