RFC: Parallel states - Proof of Concept code

[christopherthielen]

Plunkr: http://plnkr.co/edit/IgePmCtVnojo19i3y6Ab?p=preview
Updated Plunkr: http://plnkr.co/edit/YhQyPV?p=preview (2014-02-24, read comments posted on 2014-02-24)
Ui-Router Fork: https://github.com/christopherthielen/ui-router

I have a "Tabs" use case for Parallel States in each tab. Basically, my company has an non-angular application which users sit in all day long. There are multiple components, each of which lives in a separate tab, and each of which has its own complex nested state. Users switch back and forth between tabs to perform their job.

For a semi-theoretical example, let's say there are three tabs. Tab 1 is always an inbox, calendar, and task list. Tab 2 allows the user to create, view and update records and follow workflows. Tab 3 is swapped out with a variety of tools that do business work, such as billing or requisitions. Tabs operate independently, but the user needs to refer back to related data in tabs 1 and 2.

I want routing/url management, however if the user bookmarks a URL, I only care about bookmarking that particular tab. I do not need the state of all 3 tabs stored in the URL; I only need the state of the current tab reflected.

I have developed a proof-of-concept that shows how this could be implemented in ui-router. In my proof-of-concept, a ui-view may be tagged with "parallel-state" and multiple ui-view(s) may be added to the parent state's template. When a state transition occurs between the parallel branches, the "exited" state's locals and DOM is retained.

The plunkr demonstrates the parallel routes, via a tabbed UI. Click around in the UI (select "Show inactive tabs" to get a better idea of what is happening)

I'd like to hear comments and opinions about the approach. I'm new to ui-router, so I'm sure I might have leaked or misused some abstractions that I didn't understand. I have not yet tested or accounted for all ui-router functionality, like state parameters and resolves.
However, does this look like a reasonable approach to parallel routes?

I'd reference the other parallel state issues, if I knew how.
#475
#562
#63
#863

[timkindberg]

Just real quick... one of the coolest fucking things I've seen created with ui-router yet.

I am having trouble figuring out what features are coming from your modifications to the src and what features are coming from the boilerplate in your script.js plunkr file. Like, what could you do without all the extra helper functions everywhere? Or are those required? Obviously this is just an RFC, I'm just trying to get a feel for what is in included and what isn't.

So looking at it more. Seems like the parallel aspect is included in the src changes, so we get:

• parallel views and states, that when active show their url in the address bar
• the state will retain its data unless you leave its parent state, then if you return the data and view starts from scratch

The boilerplate gets us:

• the showing/hiding of the tabs (see I think this should be more baked in)
• The returning to child states within a tab (also wondering if this can be more baked in)

I wonder if instead of using a parallel-state directive we just have an extra parameter on the config and tap into the named view feature that already exists, so the children say what view they plug into instead of the view saying what child state will plug into it.

In root.tabs template:

...
template: '  <div ng-show="isTabVisible(\'root.tabs.S1\')"><div id="root_tabs_ui-view_S1" ui-view="S1">Nothing Loaded</div></div>' +
...

Then in root.tabs.S1:

$stateProvider.state('root.tabs.S1', {
        controller: timerCtrl,
        template: 'whatever',
        scope: true,
        parallel: true,
        parallelView: 'S1',
        url: '/s1'
    });

I'd have more feedback but I'm curious what @nateabele, @MrOrz, and @empaempa think about it.

[christopherthielen]

Thanks for looking at this, and I'm glad you think it's cool. That hopefully means I'm on the right track.

Your analysis is correct. The modifications to ui-router allow parallel states that can be bound to ui-views. The module code implements the tabs state management and UI (i.e., it uses the parallel state support from the ui-router modification to implement parallel tabs).

I took a hint from some previous comments on the issue tracker that "tabs" themselves are outside the scope of ui-router, so I intentionally kept all the "tabby" stuff in my module. The controller for "root.tabs" contains most of the tabby logic and could (probably should) easily be converted to a directive. I have put about 12 hours into this so far, attempting to attack the problem from 4 or 5 different angles, so I wanted to make sure I'm on the right track before dumping more time into improvements.

Edit: Ooops, I misinterpreted your comment and made a huge reply based on my misinterpretation. I'm leaving this up for posterity

Regarding the markup convention I implemented, I tried a number of different mechanisms before settling on <ui-view parallel-state=".S1">.

Here are some thoughts:

Parallel states must be direct substates of the parent state. Your comment about the parallel-state attribute can be deconstructed to: How do you (a) declare the parallel states and (b) bind those states to ui-views from the parent view.

In my example, parallel-state=".S1" isn't actually a directive, it's just a data attribute that ui-view uses. I had at first used <ui-view=".S1"> but I thought that didn't provide an explicit "parallel" marker for readers of the markup, since parallel views are significantly different from <ui-view> and <ui-view="viewname">. When declaring a state with multiple named view references (note: not parallel states), those views are part of the state, as opposed to a "raw" <ui-view> which creates a placeholder for the next nested state to attach. <ui-view parallel-state=".S1"> is a hybrid of the two in that it uses the "raw" ui-view but is still parameterized, and doesn't confuse me as to what should happen. The "raw" nature of the ui-view tag (<ui-view parallel-state=".S1">) hints to me that it is not a placeholder for a view within the current state, but rather a placeholder for a child state. All that said, however, <ui-view=".S1"> feels reasonable to me as well.

I don't like that the ui-view in my proof-of-concept is explicitly referencing a child state as opposed to a view, which I think is your objection as well. My rationalization for referencing the state as ".S1" is that a raw <ui-view> is referencing the child state, implicitly (I realize this isn't really a good argument since multiple different child states could be loaded into that <ui-view>).

If we ran with your suggestion, parallel: true and parallelView: 'S1' are redundant. If we used only parallelView: "substate1" and then <ui-view=".substate1"> (note the dot notation to denote sub-state) would that smell better to you?

<ui-view=".substate1">

$stateProvider.state('root.tabs.S1', {
        controller: timerCtrl,
        template: 'whatever',
        scope: true,
        parallelView: 'substate1',
        url: '/s1'
    });

Either way, I am definitely trying to link the ui-view to a specific substate, whether that is direct by referencing the substate name, or via a parallelView name (unique among all the child states) found by checking all parallel child states.

Food for thought, here are some of my failed approaches:
(1) My first approach was to try with a directive that canceled $stateChangeSuccess event propagation.
(2) My second approach baked into ui-router a "parallel state container" concept, of which all direct substates were made parallel. This boiled down to creating a state (root.tabs) that was marked as something like parallelcontainer: true. I had problems accessing those substates' views when rebuilding the view tree (during directive compile and updateView() steps), but that was early in my exploration into ui-router and in hindsight, it may be an achievable approach.
(3) My third approach was a variation on my second, where I defined multiple named views on the parent state, as peers to standard named views. Those views then referenced the state they wanted loaded in that view. views: { S1: { state: 'root.tabs.S1' }, S2: { state: 'root.tabs.S2' } } Again, I had troubles loading the appropriate controller/template because I was trying to load locals, etc for children states and it didn't make sense.

Finally, I decided to try to embrace the currently built-in "raw" ui-view mechanism. I noticed that multiple <ui-view> <ui-view> would get loaded twice with the current state, so I tried short circuiting the load process when the parallel-state attribute didn't match the $current state. That way the correct state's ui-view is loaded when $current matches that state, but is not touched otherwise.

[christopherthielen]

Tim, I just realized I completely misunderstood the point of your suggestion. I'm leaving my last comment up for posterity, maybe there's something discussion worthy in it.

I wonder if instead of using a parallel-state directive we just have an extra parameter on the config and tap into the named view feature that already exists, so the children say what view they plug into instead of the view saying what child state will plug into it.

If I had read your comment more carefully I would have noticed the most important part.

Is there a precedent for child states going "up the chain"? The way I currently think of views and states is that the parent state chooses a view whose template is responsible for plugging in the child, via ui-view placement.

[christopherthielen]

I converted the tab handler to directives and changed the ui-view syntax to <div ui-view=".substate">
Updated plunkr: http://plnkr.co/edit/OlBZkZ?p=preview

The relevant markup now looks like:

  // The tab list state
  $stateProvider.state('root.tabs', {
    controller: function ($scope, $state, $timeout) {
      timerCtrl($scope, $state, $timeout);
      $scope.isStateActive = function (statename) {
        return $state.includes(statename);
      }
    },
    template: '<b>root.tabs</b>: Started {{delta}} seconds ago' +
            '<input ng-model="data" type="text">{{data}}' +
            '<br><input type="checkbox" ng-model="showInactiveTabs">Show inactive tabs' +
            '<ul class="tabs" parallel-state-controls>' +
            '   <li ng-class="{ active: isStateActive(\'root.tabs.S1\') }" parallel-state-selector=".S1">S1 (Parallel State 1)</li>' +
            '   <li ng-class="{ active: isStateActive(\'root.tabs.S2\') }" parallel-state-selector=".S2">S2 (Parallel State 2)</span>' +
            '</ul>' +
      // Here is where the parallel states are bound to the UI.  I'm using the .SUBSTATE nomenclature to
      // mark a ui-view as following a parallel state tree.
      // Note: Wrap the ui-view in a div because ng-show doesn't seem to work on a ui-view
            '  <div ng-show="showInactiveTabs || isStateActive(\'root.tabs.S1\')"><div id="root_tabs_ui-view_S1" ui-view=".S1">Nothing Loaded</div></div>' +
            '  <div ng-show="showInactiveTabs || isStateActive(\'root.tabs.S2\')"><div id="root_tabs_ui-view_S2" ui-view=".S2">Nothing Loaded</div></div>' +
            '',
    url: 'tabs'
  });

With all the fluff removed, here is the bare bones markup:

<ul parallel-state-controls>
   <li parallel-state-selector=".S1">S1 (Parallel State 1)</li>
   <li parallel-state-selector=".S2">S2 (Parallel State 2)</li>
</ul>
<div ui-view=".S1">Nothing Loaded</div>
<div ui-view=".S2">Nothing Loaded</div>

[timkindberg]

Ha I love when someone is so excited they write about 2000 words and 2 directives before I even get back.

So let me start with a disclaimer. UI-Router is in big flux right now with the bower issue, @nateabele has about 100 local refactors he has yet to commit, and several medium sized features that are still in the 'baking' process. With all of that, this is probably not on a high priority list (mainly because its large size), but its really cool and its something I know devs have wanted multiple times, so its a good thing to explore (and you seem to have the smarts to explore it properly).

Basically the less intrusive that the changes are in the source, and the less conceptual overhead it adds to ui-router, means the more likely it will get in quickly. @nateabele and I are really stubborn on API elegance (esp since there's already several concepts in ui-router that are not easy to grasp at first blush). Anyway, if that's all good with you we can continue to explore this.

Ok so your question from two comments up first:

Is there a precedent for child states going "up the chain"? The way I currently think of views and states is that the parent state chooses a view whose template is responsible for plugging in the child, via ui-view placement.

Yes I think this is how it currently works. A parent state template can define multiple named views as such:

<div ui-view='a'/>
<div ui-view='b'/>
<div ui-view='c'/>

But its the child state that decides how to fill those shells:

$stateProvider.state('child', {
  views: {
    'a': ...,
    'b': ...,
    'c': ...,
  }
})

To me, this is going 'upwards'.

Now for your comment above (with the new directives and markup). This does feel a lot better, perhaps we'd roll all the directives into the module. I'm not fully liking the ui-view=".S2" though. That's not what I'd originally proposed, but I don't like what i originally proposed either anymore. I kind of like using the 'pipe' as seen in #863, but we don't need anymore special syntaxes. I wonder if just using a new directive called ui-parallel-view would be a good option?

<ul parallel-state-controls>
   <li parallel-state-selector=".S1">S1 (Parallel State 1)</li>
   <li parallel-state-selector=".S2">S2 (Parallel State 2)</li>
</ul>
<div ui-parallel-view="S1">Nothing Loaded</div>
<div ui-parallel-view="S2">Nothing Loaded</div>

I removed the dot before the state names, but I'm not sure if that's good. They do help show that its children states when the dot is there. But then I think it may also make ppl feel as though they can use any relative or absolute state targeting string there (e.g. '^', '.child.grandchild', '^.sibling'); could they? Would they?

I think we need more brains in here.

[christopherthielen]

Yes I think this is how it currently works. A parent state template can define multiple named views as such:
...
But its the child state that decides how to fill those shells:

Aah I see. I haven't used multiple named views, so I misunderstood what was going on with them.

You don't like ".S1", but is it primarily because of the potential user confusion on what they can put there? Of course those cases could be guarded during compile time, i.e.

          if (name.indexOf(".", 1) != -1 || name.indexOf("^") != -1)
            throw new Error("ui-view='" + name + "' illegal substate reference.  You can only reference direct child substates. ");

That said, the more I consider your idea, the more I agree it makes sense.

<ul parallel-state-controls>
   <li parallel-state-selector=".S1">S1 (Parallel State 1)</li>
   <li parallel-state-selector=".S2">S2 (Parallel State 2)</li>
</ul>
<div ui-parallel-view="S1">Nothing Loaded</div>
<div ui-parallel-view="S2">Nothing Loaded</div>

Is this more along the lines of what you're thinking?

var substate1 = {
   url: ..., name: ..., 
   views: {
     S1: { template: '', controller: function() {} }
   }
}
var substate2 = {
   url: ..., name: ..., 
   views: {
     S2: { template: '', controller: function() {} }
   }
}

[timkindberg]

Is this more along the lines of what you're thinking?

Yes it is. I'm still undecided if the substate should have to use the views property or if the ui-parallel-view directive can just specify the child state. Its more annoying to have to specify the views property but also more consistent API-wise with multiple named views.

I'll have to think more about this. Meanwhile hopefully some more people chime in before we go to far in any one direction.

[christopherthielen]

Updated plunkr: http://plnkr.co/edit/YhQyPV?p=preview

I've made some more progress on this:

• Migrated from ui-view-based logic to state transition-based logic.
• Decoupled parallel code from main ui-router code (I extracted the bulk of the code into a $parallelState provider)
• Added handling for state parameters and resolve
• Added support for a parallel tree nested inside another parallel tree
• Changed markup syntax to standard named view syntax

I need this feature for a project I'd like to port to ui-router, so I'm going to continue plugging away (or should I say "plunk'ing away"?). Hopefully I'll get more feedback from the other players.

Tim, I took your disclaimer to heart:

So let me start with a disclaimer. UI-Router is in big flux right now with the bower issue, ... this is probably not on a high priority list (mainly because its large size), but its really cool and its something I know devs have wanted ...

Basically the less intrusive that the changes are in the source, and the less conceptual overhead it adds to ui-router, means the more likely it will get in quickly ... Anyway, if that's all good with you we can continue to explore this.

I revamped the way nested parallel states plug into their parent ui-view. I went with your suggestion about the parallel state having a named view which plugs into the matching named ui-view in the parent template. Now that I understand how regular named views work, this makes sense and seems consistent. It also simplified/removed a bunch of the code I was kludging before.

By extracting most of the code to a $parallelState, the integration points become simple and apparent. Have a look at my fork again. There is a lot of added code (plunkr code and parallelState.js), but the important conceptual changes are found in state.js and viewDirective.js.

The following 5 integration points are confined to three functions: registerState(), transitionTo(), updateView(). Check the diffs ( https://github.com/christopherthielen/ui-router/compare ) for exactly what changed in state.js and viewDirective.js. The 5 integration points are as follows:

1) during registerState, if the state is defined as parallel, then register it with $parallelState

  function registerState(state) { ...
    if (state.parallel) $parallelStateProvider.registerParallelState(state);

2) Reactivate parallel state

Normally, during transitionTo we check for the states that are "kept" and reuse those locals. Any non-kept additional substates are resolved by calling resolveState(). When those states are resolved, then the transition occurrs.

Instead, we now first check if we are transitioning back to a previously inactivated parallel state. If so, restore locals from $parallelState instead of calling resolveState(). Make a note that we did this by adding the state name to a local variable "restoredStates". We'll use that after the transition occurs to notify the states via onEnter/onReactivate

      var restoredStates = {}; // Used after all states are resolved to notify $parallelState
      for (var l=keep; l<toPath.length; l++, state=toPath[l]) {
        var restoredState = $parallelState.getInactivatedState(state, toParams);
        locals = toLocals[l] = (restoredState ? restoredState.locals : inherit(locals));
        if (restoredState) {
          restoredStates[state.name] = true;
        } else {
          resolved = resolveState(state, toParams, state === to, resolved, locals);
        }
      }

3) Register "exited" (inactivated) parallel states as inactivated

After transitioning states, we normally locate exited states and execute their callback "onExit".

Instead, check if we are "exiting" a parallel state that should continue to live as an inactivated parallel state. Instead of exiting the state and removing its locals, register the state as Inactivated via $parallelState, then execute the callback onInactivate (as opposed to onExit). Notify $parallelState of any states that were actually exited, so we can check if this orphans any descendant inactive parallel states.

        // Check if we are transitioning to a state in a different parallel state tree
        // fromPath[keep] will be the root of the parallel tree being exited
        var parallel = keep < fromPath.length && fromPath[keep].self.parallel;
        // Exit 'from' states not kept
        for (l=fromPath.length-1; l>=keep; l--) {
          exiting = fromPath[l];
          if (parallel) {
            $parallelState.stateInactivated(exiting);
          } else {
            $parallelState.stateExiting(exiting);
            if (exiting.self.onExit) {
              $injector.invoke(exiting.self.onExit, exiting.self, exiting.locals.globals);
            }
            exiting.locals = null;
          }
        }

4) Reactivate previously inactivated parallel state(s)

After transitioning state, we normally invoke the onEnter callback for any added states.

Instead, we first check if the newly added states were re-activated (via integration point #2, above). If so, notify the parallel state it has been reactivated, and remove it from the inactive parallel state registry

        // Enter 'to' states not kept
        for (l=keep; l<toPath.length; l++) {
          entering = toPath[l];
          entering.locals = toLocals[l];
          if (restoredStates[entering.self.name]) {
            $parallelState.stateReactivated(entering);
          } else if (entering.self.onEnter) {
            $injector.invoke(entering.self.onEnter, entering.self, entering.locals.globals);
          }
        }

5) Short circuit ui-view's updateView()

Normally, after a successful state transition, all ui-view(s) will update themselves. The ui-view might re-initialize itself (and thus, all its sub-views) if the state mapped to it has changed.

Instead, check if the state transition is changing from this parallel subtree (or "universe") to another peer parallel subtree. In other words, the state was on a substate of one parallel tab, then the state transitioned to another substate of a parallel tab, a peer tab to the first. If so, then short circuit the ui-view's updateView. This leaves the DOM intact and doesn't rebuild the view subtree.

        var eventHook = function (evt, toState, toParams) {
          if (viewIsUpdating || $parallelState.isChangeInParallelUniverse(view, evt, toState)) {
            return;
          }

[timkindberg]

Wow man! Just amazing. People are really going to like this and I really appreciate you working on this so thoroughly. This really epitomizes "contributing".

I know you've already put so much effort in and honestly it is usable the way it is, and not overly confusing (which is good for a new concept like parallel states), but I did have some more thoughts, but don't feel like you have to entertain every little whim that comes to my mind, but I'll say them anyway.

The two new directives (parallel-state-controls and parallel-state-selector) feel a bit odd to me. Now maybe this is because you felt you needed to keep them as separate from the src changes, but I'm really rethinking that notion. Now if we keep them that's fine—that was actually another side question I had: were you thinking that these directives would be part of ui-router core? Anyway, these two directives really just do a couple things (from a end users perspective); 1) parallel-state-controls allows you to do a 'deep' reactivation and 2) parallel-state-selector just activates a parallel state.

I was thinking instead of parallel-state-controls, we could just have another state config option called retainDeep: true, which during reactivation will automatically navigate to the deepest child that was active before inactivation, retaining all locals as well. Just like you are already doing but basically using a state config boolean instead of a directive.

Additionally, is there a reason why we couldn't just use ui-sref instead of parallel-state-selector?

I'm fine with baking all of this functionality into ui-router. I think others will be too, screw whatever has been said before. This is a slightly newer spin on the concept that I believe works with core. Now this is all naive to whether this is technically possible, so maybe its not doable.

Some other thoughts:

• Could a parallel state fill more than one named ui-view? Seems like it could/should. Would that currently work?
• What is scope: true?

[christopherthielen]

Tim,
I love the idea of baking in deep state re-activation as state configuration. This could be useful for non-parallel states too.

I made some changes, updated the plunkr, and committed src changes to my fork.

Baked in deep tab state re-activation

I implemented your suggestion about configured state deep re-activation and nuked both tab control directives. This feels much cleaner! I don't think I like config option's name however, retainDeep, and I don't like any alternatives I've come up with either. For now my code is using deepStateRedirect but I'm sure there's a better name out there.

state.js integration rewrite

The 5 integration points remain the same, however I rewrote the code to hopefully be easier to comprehend.

I am now returning a parallelStateTransitionType object var ptType = $parallelState.getParallelTransitionType(keep, fromPath, toPath); which has { to: (bool), from: (bool) } to indicate if the transition is to and/or from a parallel state.

I created a function to return the type of "re-entering inactive state" transition is occurring. It indicates if we are re-activating a state with the previous locals, or if we need to re-initialize because of updated state params. This is due to a bug I found where a parallel state transition to the same parallel state with different params wasn't treated properly. (I've added a state param to root.tabs.deep and controls in root.tabs.deep.deep.nest in my example which demonstrates the fix)
var pEnterTransition = pEnterTransitions[l] = ptType && ptType.to && $parallelState.getEnterTransition(state, toParams, ancestorParamsChanged);
Enter transition can be either "reactivate" or "updateStateParams". During updateStateParams, we treat it as an exit/enter, not a reactivation. If an ancestor updated their state params, all descendants will also exit/enter.
ancestorParamsChanged = (pEnterTransition == "updateStateParams");
Now we have set up a nice way of checking how to load locals:

         if (pEnterTransition == "reactivate") {
           locals = toLocals[l] = $parallelState.getInactivatedState(state, toParams).locals;
         } else {
           locals = toLocals[l] = inherit(locals);
           resolved = resolveState(state, toParams, state === to, resolved, locals);
         }

And a nice way to determine if we should onExit or onInactivate:

          // Treat parallel transition type "updateStateParams" as an exit/enter
           if (ptType && ptType.from && pEnterTransitions[l] !== "updateStateParams") {
             $parallelState.stateInactivated(exiting);
           } else {
             $parallelState.stateExiting(exiting);

And a nice way to determine if we should onEnter or onReactivate:

          if (pEnterTransitions[l] == "reactivate") {
             $parallelState.stateReactivated(entering);
           } else {
             $parallelState.stateEntering(entering, toParams);
             if (entering.self.onEnter)
               $injector.invoke(entering.self.onEnter, entering.self, entering.locals.globals);
            }

questions

Could a parallel state fill more than one named ui-view? Seems like it could/should. Would that currently work?

Yes, I see no reason it wouldn't work currently but I haven't tried it.

What is scope: true?

Nothing to see here, move along. (copy/paste stupidity)

state transition thoughts

I have been thinking about controllers that want to know when they're being transitioned away from. Currently, a controller can intercept stateChangeStart and check if they have dirty data that needs to be saved, etc. With state inactivation, this concept no longer makes sense. We need to add a way to check if the controller is about to be inactivated, as opposed to about to be exited.

[timkindberg]

So. Fucking. Awesome. Its so conceptually easy to pick up now, I can't believe you've done all of this man. I really still want @nateabele to take a look, I think he's a bit busy lately (aren't we all).

I was wondering if instead of setting parallel to true or false, maybe set it to either "shallow" or "deep". That would eliminate the deepStateRedirect property.

I'm really surprised others haven't chimed in yet either.

[christopherthielen]

• I like "deep state redirect" as a separate option from the "parallel" option. I can imagine a use case for implementing non-parallel tabs system, where each tab gets rebuilt when activated, but the deep redirect is still used. parallel: false, deepStateRedirect: true
• I had another thought about deepStateRedirect: true alternatively being set to something like deepStateRedirect: 'localStorage:myapp.mylasttabstate' or deepStateRedirect: 'cookie:myapp.mylasttabstate' and persisting stuff to the browser. Or what if it optionally took a function deepStateRedirect: myFunction that determined where to redirect to...

But then we are adding complexity. I'm thinking of a comment by @nateabele in issue 618... are those suggestions a "10-lines-of-user-code" scenario?

No internal changes required, which means you have complete control over the implementation, which avoids future RFCs requesting additional configurability for whatever theoretical solution we might implement, which means I have more time and energy to spend implementing things this module isn't currently capable of, rather than merely making things that are already possible 10-lines-of-user-code easier.

• Now that I've analyzed this problem more, does "parallel" conceptually still make sense, or does something more like "retain" better convey what is happening? The crux of the feature is as follows

  If a transition from some state A -> state C "pivots" over an ancestor state B where B is parallel: true, then retain the DOM tree of B and track the states behind that B tree as inactivated states.

[timkindberg]

I think persisting can come later, we don't want to do too much until there is a valid outcry for it. I think both 'parallel' and 'retain' make sense to me. 'retain' may be a bit easier conceptually—"I want my stuff to stick around". Some people call them "sticky views" as well. So something like "sticky" could also work. "parallel" is certainly more technical sounding. We still need @nateabele to take a look too.