Add children option to state configs

[ProLoser]

Would be an array of states (strings/objects). This would allow us to attach a child to multiple parents, thereby allowing amazing code reuse (and opening up the opportunity for truly pluggable modules).

If you create a path-relative (agnostic) implementation of an 'edit' module, you could attach it to both a person and project and task module and get some excellent code reuse across the board.

[timkindberg]

This is quite a large size item. I'm so not sure how I envision "pluggable modules" to work yet. Maybe this way, maybe some other way. This idea doesn't feel so bad. We'll definitely have to let it stew though, at least I will.

[ProLoser]

Actually when I was poking around the code, it appeared that the way states and their relationships are resolves is that child states are pushed into a children array that's a property of the parent state. So theoretically it'd be fairly straight-forwards to add support for a children property. Especially since the newest version (supposedly) resolves routes just-in-time, then I would imagine the logic that resolves the relationships and where the relationships are defined is completely isolated from one another.

[CMCDragonkai]

I would definitely like this! One use case is "modal" states, which can be child states of multiple modules. Might want to consider multiple inheritance too.

[CoderSpinoza]

Sounds amazing.

[timkindberg]

I was thinking about this yesterday and it would actually be awesome. So I think it would need to be a merge of auto added children (states that were added based on the dot-syntax naming scheme) and children pushed into the array manually (regardless of their name).

[timkindberg]

@marklagendijk was gonna work on adding this property based on naming schemes (which is related but not exactly what this story is going for). See #903.

[ProLoser]

So after reading @marklagendijk I realized that the one flaw with this design is duplicate state names in your tree. I am very reserved about modifying explicitly state names because I use a combination of parent.child and parent:parent to keep state names short and concise. We COULD do what he proposed and convert all names to long form, and even go so far as to allow you to specify the end of a name for conciseness, but this would be unreliable, and easily break.

Instead what I have been doing is declaring a state object and reusing the object in multiple state() calls where I still explicitly defined the name myself. Although this works for now, perhaps to better decouple the code we can do state aliasing.

Let's say I define an 'edit' edit modal state in my edit module. In my person module I define my 'person' state but I could also define a state like this:

$stateProvider.state('person.edit', 'edit')

This way I define a new, explicit and unique name and the original state definition for edit is simply looked up and copied over. All states defined in this manner would have to be deferred however until after all normal states are finished being defined.

Alternatively the children property could be an object of alias to original names.

[timkindberg]

yeah, I like your psuedo code there $stateProvider.state('person.edit', 'edit'). And it would just essentially copy over the config from 'edit'. Just wondering if the reusable states should be declared in a different way, e.g. $state.reusable('edit', {...config...}).

Either way this is technically a duplicate issue, because we've talked about state "modules" a long time ago. But we can leave this open because if we close it as a dupe, it will surely kill it.

[ProLoser]

I don't want to define reusable ones differently.

Could do

children: {
'person.edit': 'edit'
}
On Mar 13, 2014 12:37 PM, "Tim Kindberg" [email protected] wrote:

yeah, I like your psuedo code there $stateProvider.state('person.edit',
'edit'). And it would just essentially copy over the config from 'edit'.
Just wondering if the reusable states should be declared in a different
way, e.g. $state.reusable('edit', {...config...}).

Either way this is technically a duplicate issue, because we've talked
about state "modules" a long time ago. But we can leave this open because
if we close it as a dupe, it will surely kill it.

Reply to this email directly or view it on GitHubhttps://github.com//issues/953#issuecomment-37577232
.

[ProLoser]

So I realized that my attempts to reuse the same state object were actually causing problems. Doing this:

var state = {
      templateUrl: 'modules/projects/project/dataset/history/history.html',
      controller: 'History'
};

$stateProvider.state('project.dataset.history', state);
$stateProvider.state('project.master.history', state);

Is causing the state to always be the last one defined project.master.history. If I GO to project.dataset.history there are no errors but the state that is reached ends up being project.master.history. So obviously information is stored on the state objects. I suppose I could clone the objects for now until a proper approach is tackled for children.

[schmod]

If we implement this, we'll also need to think about how we could handle dynamic view targeting.

For instance, if I have more than two levels of heirarchy, child states will need to be able traverse their ancestors to find the appropriate <ui-view>.

Currently, a child state cannot access a <ui-view> in its grandparent without knowing the grandparent's name (thus, using absolute targeting).

(And yes, this is definitely a feature that I would make heavy use of.)

[ProLoser]

I am pretty sure you can use the ^ syntax, no?
On Apr 23, 2014 11:33 AM, "Andrew Schmadel" [email protected]
wrote:

If we implement this, we'll also need to think about how we could handle
dynamic view targeting.

For instance, if I have more than two levels of heirarchy, child states
may need to be able traverse their ancestors to find the appropriate
.

Currently, a child state cannot access a in its grandparent
without knowing the grandparent's name (thus, using absolute targeting).

(And yes, this is definitely a feature that I would make heavy use of.)

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

[schmod]

I don't believe that you can target states using the $state.go() syntax when defining views...

[timkindberg]

@schmod true. You can only use view@state syntax.

[eddiemonge]

Can this be closed or is it still needed?