Complex Dynamic Routes

[austincondiff]

I have a fairly complex route that is required by my project. Looking through documentation, I am not too sure this is possible (please try to prove me wrong), however if it is not it might be nice to be able to allow this type of behavior. I apologize in advance for the length of this issue, however this is a fairly in-depth concept that needs to be properly explained to be understood.

To get started, I have a parent state, and two child states that are siblings.

The resulting route would look like this:
/:userSlug/:tabSlug/entry/:entrySlug
or
`/:parent/:childA/text/:childB'

As you can see in the diagram the parent ui-view is the user page, the first child is a tab area, and the area to the right of the left pane is the entry being displayed or the second child.

An entry does not need to be selected so the url could look like this
/:userSlug/:tabSlug

And the UI would then look like this:

Now as far as I can tell, named views within a state definition cannot have a url.

The requirement I have is that the userSlug be changeable while maintaining its child. This means I should be able to change users while not reloading the child entry state. I should also be able to change tabs within the user page without reloading it's sibling entry state.

The last stipulation, is at the top there is a search bar. It also acts as the title bar. You type in it and get suggestions of users' pages and when clicked it will load their page (while maintaining your entry if you are viewing one). The user page also needs to maintain it's controller and view without a state reload. One thing to note, the user page and tabs that are displayed are controlled by a user object I am getting from an API call in my resolve method in the state definition which is being injected into my controller. I can just replace the user object and somehow manually rewrite the url, but I would need to keep track of the different state parameters now that it is in a somewhat unstable state and that could get pretty messy.

A prime example of this in action however is Google Maps. There is a search bar which contains the name of the place that is being displayed. The url initially shows /@:coordinates.

When you click on a named place on the map and it populates the left pane and the route changes to /places/:placeSlug/@:coordinates.

Clicking on subsequent places simply replaces /:placeSlug before your coordinates.

I do not believe the coordinates are a query string because there is not a question mark before it all.

So is this just some crazy pipe-dream or is this at all a possibility? If it isn't would ui-router benefit from being able to handle complex routes like this? Through countless Google searches I have read of quite a few people wanting to do pieces of this. Anyways let me know what y'all think.

[nateabele]

Yup, full dynamic parameter support is coming in 1.0 and will cover this use case.

[austincondiff]

All of that will really be supported? Wow i am impressed if that is the case. Do you have any kind of a timeline for when that would be released? I need it to complete my project.

[austincondiff]

What about the /:parent/:childSiblingA/:childSiblingB url and different pieces not having to reload their controller/views?

[nateabele]

Yeah, you can choose to make any/all parameters dynamic.

[austincondiff]

Can you explain what exactly you mean by making the parameter dynamic? That can mean several different things. Is there any documentation written yet on this new feature? Also is there a timeline as to when it will be released for production use?

[Nandan108]

Hi @acondiff acondiff. If I understand correctly, dynamic params mean that the URL params are mapped to objects that are watched by the router. When the objects mutate, the router calls functions you provide to serialize each object's new state back into the corresponding URL part, and the URL is updated with no reloading of controllers.

I've been wanting to use this feature since it was announced in early 2015, but gave up and used some ugly workarounds with controller reloading. Still waiting though.

@nateabele I've just used used Burndown (http://burndown.io/#angular-ui/ui-router/1) to check out the progress rate of the 1.0-preview milestone. If the amount of effort doesn't change, we can project a completion date around end of 2016 or early 2017. It might be good to be explicit about that.

[photusenigma]

+1 for timeline?

[nateabele]

https://github.com/angular-ui/ui-router/releases/tag/1.0.0alpha0

[eddiemonge]

Seems like this is closed as it should be able to be handled by 1.0.0, is that right?

[nateabele]

By my understanding of @acondiff's needs, yes.

[christopherthielen]

I think 1.0 still requires some work for dynamic params to be usable.