RFC: Leaving specified views intact during state transitions

[MrOrz]

I would like to send a pull request proposing a solution to #63 and #317, with two lines of code modification.

MrOrz/ui-router@angular-ui:master...patch-1

Summary of Changes

The template string of a state can be set to =. When entering such state, the named views with its template set to = will remain intact. Neither the scope nor the DOM will be destructed.

When = is introduced, implementing modal dialogs with ui-router can be straight-forward. I humbly provide a few motivating examples in the following sections. For each example, click "Edit in JSBin" button on the upper right corner to view its source.

---

Usage Example

// A page that lists all the items.
// Clicking the items will show the details in a modal dialog.
//
$stateProvider.state('index', {
  url: '/',
  templateUrl: 'index.html'
});

// The detail pages. 
// Populates "modal" view and keeps the main view.
//
$stateProvider.state('detail', {
  url: '/detail/:id',
  views: {
    '': {
      template: '='
    },
    modal: {
      templateUrl: 'modal.html',
      controller: modalCtrl
    }
  }
});

HTML Setup: Two ui-views, side-by-side.

<div ui-view></div>
<div ui-view="modal"></div>

Proof of Concept

http://jsbin.com/AYoKuHe/latest#/
Each "detail page" can be accessed individually via URLs. All the states are correctly managed by ui-router.

Notice that when the modal opens, the underlying index is still visible.

This is achieved by setting the template of main ui-view to = while in the "detail" state.

When the detail page is accessed directly via URL, the underlying page is blank.
http://jsbin.com/AYoKuHe/latest#/detail/4

Adding some simple trick and CSS magic, the detail pages can be shown outside of a modal when their URLs are directly accessed.
http://jsbin.com/itOjaj/latest#/detail/2

Notice the detail pages can still be viewed in modal after navigating to the index page. The behaviour is exactly the same as Facebook albums and Instagram colorboxes.

Integration with ui-modal

See it in action: http://jsbin.com/aFemAfe/latest
Individual detail pages are shown outside the modal: http://jsbin.com/aFemAfe/latest

The trick here is to move ui-view="modal" around. Kind of stupid, but it is somewhat better than fighting bugs caused by preventing state changes.

[timkindberg]

Wow this is pretty bad ass... I'm trying to find holes in it though. I'll let you know.

[timkindberg]

1. So if a much deeper nest state wanted to set a top level view in the same manner would you need to set every other possible ancestor view to '='?
2. Also not digging using '=' so much, we already have ^ and @, I think we should be more explicit. I would prefer a special string like '$retain' or a config property retain: true. Not saying 'retain' has to be the word but you get what I mean.

[nateabele]

Certainly looks interesting. After a cursory review, the code looks okay, but one thing I noticed is that if you refresh, you lose the modal overlay. Did I miss a part in the description where this was intentional?

[deedubs]

Could we not make changing a named view opt-in? So you don't need '=' or retain, just don't specify a change?

Continuing with the above example

$stateProvider.state('detail', {
  url: '/detail/:id',
  views: {
    modal: {
      templateUrl: 'modal.html',
      controller: modalCtrl
    }
  }
});

I may be missing something obvious as I'm pretty new to ui-router...

[timkindberg]

@deedubs that makes too much sense. But I haven't thought deeply about the implications. Seems like it would make for good usability from an API perspective too! I like it.

[Cinamonas]

This is a very welcome addition! +1

[jonrimmer]

I don't see how this would solve #63, as the tabs use-case requires that you keep the view/controller around when the ui-view it's attached to changes, not when an unrelated named view does. The best option for #63 remains some kind of caching capability on ui-view, IMO.

This is a pretty neat idea though, and would very useful for modals, other overlays, and things like sign-in dropdowns. Although for those, I would still prefer the ability to create additional state machines that could be independently serialized to and from the URL.

[RBLU]

Really like this and tried in our current app, works nicely, but I had to change your locals-comparison because it broke most state transitioning in our app (angular.equals ignores all properties starting with $ so it ignored many state changes) (using 1.2rc3)

if (locals === viewLocals || /* fast-check the obj references */
                  (locals && viewLocals && /* deep-comparing essential elements */
                      angular.equals(locals, viewLocals) &&
                      angular.equals(locals.$stateParams, viewLocals.$stateParams)) ) return;

I made it working like this:

if (locals === viewLocals || /* fast-check the obj references */
                  (locals && viewLocals && /* deep-comparing essential elements */
                      angular.equals(locals.$$state, viewLocals.$$state) &&
                      angular.equals(locals.$stateParams, viewLocals.$stateParams)) ) return;

[Cinamonas]

@RBLU That's exactly what I was about to report :) Relevant line in angular.equals source.

[RBLU]

made it working like this:

if (locals === viewLocals || /* fast-check the obj references /
(locals && viewLocals && / deep-comparing essential elements */
angular.equals(locals.$$state, viewLocals.$$state) &&
angular.equals(locals.$stateParams, viewLocals.$stateParams)) ) return;

well, this quick fix is obviously not good enough. It needs both lines, the one I added and the one I replaced, otherwise the state is not updated when the locals ('resolves') change. So, better is:

if (locals === viewLocals || /* fast-check the obj references */
                  (locals && viewLocals && /* deep-comparing essential elements */
                      angular.equals(locals, viewLocals) &&
                      angular.equals(locals.$$state, viewLocals.$$state) &&
                      angular.equals(locals.$stateParams, viewLocals.$stateParams)) ) return;

[jeme]

@jonrimmer the templates are already cached, not as a detached DOM though, but keeping controllers around may have side effects, so it's more sane if that doesn't happen as part of a router solution IMO... (Basically my advice is to not make components with a router)

A tab view should instead be a component (directive + needed services) in it self... then just switch to the right tab based on a routing parameter... It's actually not that difficult to achieve... Doing this in an explicit way rather than weaving it into the router means people can be more aware of the side effects it may have...

A Very basic solution for a single tab view can be done in 21 lines of javascript + some html... As I demonstrated in #63 ... that just shows how simple it is... making it the right way (directive+services) would require a bit more work... but really...

From here on out it makes more sense to look towards: http://angular-ui.github.io/bootstrap/#/tabs for how to combine ui-router + ui-bootstraps tabs to achieve this (in your own solution)

That is just my point of view though...

[MrOrz]

I collected some modal related issues, which are listed below. These issues comes from different use cases and has different requirements. And I also found that my proposal did not resolve #63 :P

I hope the list give us insights on where we will be heading for, as well as to understand how far we can get with the simple modification proposed in my original post.

---

#475 : Parallel state handing

We have view A and view B, and we wish to change one view without touching the other.
retain or = would work for this case. However, if there are too many states in A and B, we will have to add retain in each and every state.

By making named-view refresh opt-in, which is proposed by @deedub, the state setup would be much cleaner and more intuitive. @deedub 's idea fits perfectly into this scenario.

---

However, the retain trick would not be sufficient in solving the following issues.

#490 : is there a way to handle multiple states?

As the previous issue, we have two views that want to work separately. However, this time we need to encode all the currently active states in the views into the URL, so that the views can be rendered correctly when the user visits the page directly via URL. #123, which is similar, requires remembering the page behind the modal dialog.

#63 : Optional support for keeping a view around

This issue differs from my issue because they want to preserve the compiled DOM, scopes and the controller even after the ui-view is populated with another content.

#160 discusses a much more general case, which can achieve complex structures like widgets and portlets.

---

As for my modification to $anchorScroll, I found that its existence was already challenged in #97 XD

In fact I removed $anchorScroll merely because it will scroll my page to the top when I quit the modal dialog.

[MrOrz]

@nateabele The modal overlay is deliberately removed when the detail page URL is accessed directly.
This is to mimic the behavior of Facebook albums and Pinterest overlays.

For instance, the page http://www.pinterest.com/merblood/if-i-do/ is a list of images. When an image is clicked, a modal dialog with much detail shows up, and the URL is changed to something like http://www.pinterest.com/pin/5348093281506292/.

When we directly access http://www.pinterest.com/pin/5348093281506292/ , the detail page is shown directly, without the modal overlay.

[MrOrz]

@RBLU @Cinamonas Wow I didn't know that before :P. It seems like I have overestimated what angular.equals can do. Thanks for pointing that out and the neat patch!