Option to not skip animations when going back in history

[OSDVF]

The default swup behaviour is skipping animations when you go back in history.
I tried to animate the pages by assigning to options.skipPopStateHandling a function which always returns true (prevents the default behaviour) and loads the page by loadPage() so it does animate.
But this also creates a new entry in browser history and when you now try to go back it loads the same page over and over.
So the only way would be altering the Swup files.
Thank you for taking this into consideration

[jcklpe]

@OSDVF

I just got swup working with the wordpress theme I'm working on and I realized that it was having this behavior at almost the exact same time as you. The animation is now working beautifully but when I hit back, no more smooth transition! Would love a solution! Thanks!

[gmrchk]

This is the intended behavior. User browsing your web and clicking on links doesn't really know what's going to come, so the animation plays out as a nice thing that shortens the time to wait for the next page. However, when user clicks the back button, he expects to go back to where he was, as browser normally does.

Let's take a random page using barba as an example. When you're navigating the site, it all seems really nice, until you hit a back button. In that case, you see an animation instead of going back right away and as an addition, you lose your "scroll from top", as it always resets the scroll. This behavior is even more exaggerated on mobile/safari, where using "swipe to go back" first displays the desired page, then the previous page you were at, and then animates to the desired page again, while also losing the scroll.

I see this as terribly ruining user experience, instead of improving it. Of course, that's my opinion, so if you guys are not convinced, please present your points.

[jcklpe]

I don't think if there is a single "right" choice for back button behavior. I think a lot of it is going to be dependent upon the particular design of the website, expectations of the user which will be related to target audience, etc. So I think your points are certainly fine. I also don't have an iPhone so it's hard for me to comment as I don't have experience with that design pattern.

I think your point on hitting back and losing the scroll position is valid. That is pretty odd.

I don't know if there is anything inherently bad about not going back immediately and having the animation. I think there are trade offs there. On one hand it might be slightly slower, on the other hand it might be seen as a more consistent thread of how action and feedback are connected in the user's mental model of the interaction.

Personally for me, one reason why I would want the consistency between the two is because the website I'm building visual elements that I want to see continuously represented between pages. So for instance on the index.php I have a section to click to see a post page. The background of the section is an image that is also the Hero Image at the top of the page. Having a consistent transition back and forth between the two helps to cinch the illusion of continuous space.

You can kind of see this treatment of the hero image as continuous looking at this page here: https://tympanus.net/Development/GridLayoutScrollableContent/ Though there it's being used in a modal context so the back button is not enabled. But I think you can see what I mean if you go back and forth between the expanded and unexpanded states of the posts.

[OSDVF]

To be more specific, I want to animate every transition between pages because I´m writing a PWA which is intended to run as an "native" app on Android and iOS. All apps have animations when they switch pages/activities/etc.. so I think it would be very ugly to not have them ;)

[panayotoff]

I ran into the same issue and solved it in a little bit odd way,
I moved the transition from animations object to each page. My code is a little bit architecture-specific, but basically this is what I'm doing:

1. Every page has 'data-page' attribute that acts like Barbajs namespace;
2. All pages have controllers and listen to to swup willReplaceContent, contentReplaced, pageView and animationInDone events ( passed by event bus, ex. events.trigger('page:in', {namespace: $(pageSelector).data('page')}); )
3. I do page in animations on page 'page:in' event , then on 'page:out' event I do the out animation and return a promise.

Also in my pages I have access to previous page namespace, so I can change transitions depend on the context. This way I do not use animations object and because the swup events are triggered on prev/next browser buttons, the animation still works.

I can make medium post or codesandbox demo if someone interested.

[OSDVF]

@Panayotov Yes, that would be surely helpful for some people.
But my point was more about implementing it into Swup. (Add some option to existing ones.. e.g. animateHistoryBrowsing).
Of course I could do it (and have just done it) by myself by overriding the back button behaviour, but I just thought it may be useful for other people to have this feature integrated in Swup.

Shall I submit a pull request?

[23d1]

I can definitely see use cases for this. Would be great to have an option, whether boolean or string, depending on what variations of it might be useful... Like using a specific transition for back vs forward and whatnot...

[jcklpe]

@Panayotov I'd be interested in a medium post etc.

And I agree, it would be nice to have this option. Personally I think that giving options and making the process for choosing those options are preferable. It makes sense to have default options, and the main maintainers will probably want to focus their defaults to fit in the design choices they think are best, but I also think it makes sense that some people might have different use cases.

[gmrchk]

While I still think preserving the browser native behavior is a better choice, I see you guys have some use cases where you'd like to do otherwise. It should be fairly easy to implement this option without affecting any other functionality.

@OSDVF Definitely yes, let's see what you got!

@OSDVF @23d1 I'm thinking of adding another class on html tag for animating back, so we can differentiate between the two (forward/back) in our CSS if we need to... How about that?

@Panayotov You somehow turned the whole thing around and made it work. Nice! I would read the medium post.
Kind of makes me think of a component-based animation for swupjs (like swup has, as it waits for any animated element to finish the animation) rather than having one function doing all of it. Any ideas?

[23d1]

@gmrchk I think that sounds brilliant!

[panayotoff]

@gmrchk I have many ideas about Swup/js. I'm using it in production and had to write some common functionality.
I would add access to the DOM of the rendered page, and to each Swup outlet. For example, I have website with menu and Swup outlet, I want when page change, to get the html of the new page, make diff between new menu and old menu and create appropriate menu transition.
Also, plugin for Swupjs with minimal component lifecycle hooks ( similar of @dogstudio/highway Renderer class )
In perfect way, I see Swup as vue-router ( wuthout Vue ) for server side rendered pages.

[23d1]

Agree, access to the raw html response is very useful—I used that quite a bit in Barba, just a couple of extra steps I suppose. The good thing about Swup though, is that you can essentially just add the divs to the selectors for swapping out. Instead of having to work through raw html and update—which is kind of the same thing—at least when updating menu items. Now, if it's a matter of updating classes on menu items, I suppose that's a different story, rather than updating the full content of a div/a[href] or whatnot...

[gmrchk]

I think the focus should definitely stay on keeping it easy to implement. There are many possibilities and for some Barba or even custom solution could a better fit, but the primary reason for swup to be created was to make it possible to do such a thing in a first place. Not every project has a budget/time where you could spend days tweaking those animations/transition, dealing with browser history, etc.

You can access the raw html of any page in swup cache (or at least the one we're transitioning to, even when cache is disabled). While it doesn't have to be there at the time of starting the animation, it's definitely there right before the content is being replaced (swup:willReplaceContent event). It might not be the most convenient way, but content should be replaced by swup in most of the cases, or at least that's the idea.

Considering the menu topic, I'm not sure what's your use case exactly, but I would try to leave swup out of it all together. While swup is taking care of animations and replacing content, a menu could stay on the page and work independently. If it's about animating active items or some similar thing, we could transform the menu based on user clicks and swup events (current URL and href attribute could be used for some identification of what we want to do), in some more advanced use case, swup cache could definitely be handy as well.

A nice thing about swup is that you can let it replace even the smallest part of your page, so in case we'd like to for example animate the menu (so it can't be replaced altogether), but still would like to update the links, you can easily do that.

[gmrchk]

Fixed in 1.3.2.

It was necessary to disabled browser native scroll control when this option is enabled, as the page would first jump to its place on the previous page, and then animate. This means swup scrolls to the top (or # element if defined in URL) by default with this option.

Check readme.

Closing for now, but feel free to add any ideas.

[jcklpe]

Awesome!

[gmrchk]

and from version 1.2.0 also in swupjs