Multiple Named Views in UI Router

Question

I'm asking this to make sure I understand the concept. In UI Router, they recommend you use nested states as much as possible. However, it seems when you do that, you can only have 1 controller per state/view. Which in most cases is fine. However if you need two or more controllers on a state/view then it seems that Multiple Named Views is the right solution. Because it seems that you can actually have different html elements or divs controlled by different controllers - if necessary.

So for example on a search results page, you could have different elements or divs on the page controlled by different controllers.... is this what Multiple Named Views in UI Router is designed for?

It seems for more complex pages, like a search results page, Multiple Named Views is a better solution than simply having nested states... because you could have an Authentication controller, autocomplete controller, search controller - all being responsible for different areas on the page. I'm not even sure how you accomplish something like that with nested states.

So am I understanding this correctly?

Answer 1

I think you are confused with the fundamental definition of views and states. That being said, your understanding (to your own problem statement) is correct.

In ui-router, the fundamental principle it is making your app into a state machine. The basic definition of state machine is that, at any point of time, only one state can remain active. This is actually quite useful and a good design pattern - in a sense that you can define what your machine (or app) should do (or how it should behave) when it is in a clear defined state. Good for debugging too.

However, it doesn't mean that in a single state, the machine cannot do multiple things. It can, as long as in that state, its job is to do multiple things. Let's take a movie booking app as an example.

Disclaimer: this is not exactly a real state diagram but lets just use it for discussion purposes. Image courtesy of Google Search

Now all the blue rounded rectangular boxes are states. Meaning, when the user uses the app, at any point of time, he/she will be in one of the states - he must, or else he is not using the app.

Now it can be quickly realized that if the user is in SeatsChoosing state, he CAN'T be in other states - not PromotionSelection, not Payment, or other states, at the same time. He can go to other states (called state transition), say PromotionSelection, but only after he has done choosing. The point is that no more than one state is active here aka no Parallel States. Only one at a time.

While it only can be one state active at a time, but that doesn't mean machine cannot perform multiple tasks at a single state. Take the SeatsChoosing state as an example. In the SeatsChoosing state, multiple tasks are performed, including loading the movie, fetching the location, display the schedule, etc. But the user will experience all these things, only if he is in SeatsChoosing state. The point is you can have multiple tasks executed at the same time in a single state, as long as your state definition allows it.

And that's is exactly what ui-router is achieving. At any point of time at your app, you can only have one state active. The nested states are still a single state by itself, its just actually a node traversed down the state machine - and when you are down to that node, only that node is active. No parallel states are allowed. For the same token, it doesn't mean your state cannot do multiple things at one time. That's where named views are for. For a state, you can have different views that has different clear defined contexts (view), which all of them fall under the same domain (state) as a big umbrella.

Now lets go back to your Search Results problem statement. How do you define your state, and how do you define your views? This is entirely up to you, but just make sure if you are using ui-router, you adhere to the state machine's rules - aka no parallel states but allows parallel tasks. So if you define a state is a page that does multiple things - authentication, autocomplete, etc, then yes multiple named views is the correct way and not nested states. But if you are separating search and search results as two different domains, then, maybe nested states will be better.

There is no right and wrong answer for this, just a matter of design decision.

Hope that helps.