Multiple parents for a state

[ProLoser]

This is more of an RFC.

Lets say I have a child state I want to use in multiple areas of my app. Or perhaps it's more like a mixin, etc. How would you go about doing this? Should I define multiple parent states, or what?

[jannis-seemann]

you could create a directive for that?

[laurelnaiad]

I guess with todays ui-router I would reuse templates and controllers in each place... and put my own service on top that knows how to define the same state specs in multiple places. Having different parents will have an impact on the context (e.g. inherited state params) one way or the other so they really arent the same states even if theyre only spec'ed out once.

[ProLoser]

It actually is a directive now, but it's like a modal with a form in it. I thought it would be cool if you could use a state change to trigger the modal.

[nateabele]

This is for the login form thing? I don't think adding an extra child to every possible state makes sense here. The approach I would take is to listen for $stateChangeStart, and pass the event off to a service that checks if the user needs to log in, and triggers the dialog accordingly.

[laurelnaiad]

listen for$stateChangeStart, and pass the event off to a service that checks if the user needs to log in, and triggers the dialog accordingly

ditto, except I might have the service that does the checking be thing that does the listening. No reason that a service can't listen to $rootScope events. I actually create one service to wrap all the state events and to deal with managing transitions (I call it transitions) -- it does things like helping the app avoid trying to supercede transitions accidentally. It emits its own events to the rootScope. Another service manages session-releated stuff -- it listens to events from transitions and decides whether to interject itself to prompt a login.

[ProLoser]

Lets say it's a notes modal to add notes to this object I'm on.
On Sep 5, 2013 2:42 PM, "Stu Salsbury" notifications@github.com wrote:

listen for$stateChangeStart, and pass the event off to a service that
checks if the user needs to log in, and triggers the dialog accordingly

ditto, except I would have the service that does the checking be thing
that does the listening. No reason that a service can't listen to
$rootScope events

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

[laurelnaiad]

Well, there's an argument to be made for keeping modal's out of states altogether... or there's the $dialog sample technique, which uses onEnter to launch a modal. https://github.com/angular-ui/ui-router/wiki/Frequently-Asked-Questions#how-to-open-a-dialogmodal-at-a-certain-state -- which still doesn't have the modal as its own state, but uses a state to get it going.

Thinking out loud: seems like it would be great to have a built-in, easy to use way of transferring state to a modal -- such a state would be top-level, thus not needing a container template in which to live.

[nateabele]

So, this is something that I brought up in the initial design phase, and something that @ksperling has referred to indirectly, with respect to redesigning UrlMatcher to operate in a tree structure. But what you're suggesting requires (a) a reentrant URL parser, and (b) either a 'polymorphic' state, that can attach to any other state arbitrarily, or some notion of having multiple inter-related state trees, where you have a state active in each tree.

But I have no idea what that would look like.

[laurelnaiad]

I think independent state trees would be great -- because it would also be a helpful step toward portal-like/component support.

Would it be possible and useful to support independent state trees that are so independent that they are not related to each other (except by virtue of the application code gluing them together)?

[ProLoser]

Actually I think I created a redundant issue with #953 however it would be a far simpler approach. If a sate could define an array of children states (and multiple states could specify the same child) it would be perfect. Each instance would be isolated from each other however.

[hexadeciman]

I'm having this exact same issue and the possible solution you talked about would be perfect !

[cScarlson]

To reiterate a little...

There may be times when you have a two parent routes, say, /new & /:id but either way we want the child states of /new to be called when referencing /:id...

/new/childA
&
/:id/childA

Perhaps a "parents" array in the config will do -- OR -- a wildcard in the parent-namespace:

.state('{instance}', ...) // handles both, /new -- AND -- /:id
.state('{instance}.childA', ...)

... So that routing to any "/childA" manifests the childA state -- even if that is the only component in the route; in other terms:

.state('{REGARDLESS}.childA', ...)

I know there are other ways to get around this -- for instance -- just using a wildcard in the { url: '...' }, but in many cases this has not been the MOST-desired effect as you may want to explicate certain routes.

... However, I've been designing frameworks for a while -- but I'm still a little new to ui-router; hope I'm not speaking out of my hat.