Barba: Remove current container

[thierrymichel]

Reminder: on v1, oldContainer was removed at the end, after calling done…

What would you expect for v2?

1. Keep unchanged, at the end of the transition (after hook)
   
   
   
   • pros: same behaviour
   
   
   • cons: user needs to deal with it (e.g. current.container.remove() or display: none)
   
   
2. After the leave phase
   
   
   
   • pros:
     
     
     
     
     
     • no need to hide it
     
     
     
     • may be more intuitive
     
     
     
     • if you want to make things with both current and next container, you can "cheat" using sync: true
     
     
     
   
   
   • cons (using sync: true):
     
     
     
     
     
     • leave only starts when next container is available
     
     
     
     • leave and enter are concurrent (no necessarily wanted)
     
     
     
   
   
3. After the leave phase with an option to keep it during enter phase. (for example resolving with "something" or via a new property)
   
   
   
   • pros: same advantages as #2 with more flexibility
   
   
   • cons: adds complexity
   
   
4. Other ?

Any thoughts are welcome!

[josias-r]

I always thought it worked like the second suggestion until I came to a case where removing it at afterLeave was necessary.😂
I'd definitely go with the 3. since the added complexity is optional. I think 2. or 3. make more sense, as there is a "leave" transition with the 3 hooks and then an "enter" transition for the new page. (I actually don't even understand in what case it should be removed after everything).

As for my understanding it should work somewhat the following way with sync disabled (btw. please make a diagram or something for the docu that would help a lot😁):
beforeLeave;
leave;
afterLeave (remove current.container);
beforeEnter (add next.container);
enter;
afterEnter;

As a fourth option, why not give a property where the developer can define himself when the containers should be removed or added.

[xavierfoucrier]

Hard to deal with the current container, because there is always a case depending on the website when you need to access/remove it at a specific transition stage.

For me, as this is an "old" container, it should be hide on the interface by the new one when the transition to the next page has complete, and properly removed when the new container is ready.

So afterLeave or after hooks should do the job in most cases.

Giving the ability to the end user to specify the way the container is removed/added could enforce complexity and probably result in unexpected behaviors...

[comrx]

I like being able to control when the container is removed, but is there a way to maybe define an option for this in the transition? Like a removeContainer boolean or something similar.

[joshkirk]

Hi Thierry! This is actually a pattern that I consider crucially important when making custom PJAX websites. Having the ability to control when the old view is removed allows the developer to reliably create the illusion of persistent elements, which adds a great deal of contextual awareness for the user. An example of what I mean is if you scroll to the bottom of this page, and click to go to the next project.

It would appear that the large pink text persists across views, when in reality the new view is simply swapping with the old one at a specified time when the new view's styles are ready. So another way to describe it would be that you are not limited to simply fading out all content or covering everything with a mask of some kind. Rather, if you want, you can lock them into a transition experience that feels like they seamless move from one view/page to another.

In Highway, the way it's done is by calling from.remove(), where from is the old view container. So, minimal added code/complexity from the developer's POV.

Hope that helps!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.