Hi @ribarich @luistinygod @thomas,
it it possible to get bricks working with something like swup.js or barba.js?
The swup documentation explains pretty well where the problem is: Reloading Javascript.
I know that this is not an easy peasy 5 minute thing… but is there any chance to get this up and running?
Regards,
timmse
I haven’t used any of those two page transition libraries myself. But as they have to be implemented on the frontend I don’t see any reason why I can’t work. Is there a specific point where you are stuck at in implementing those libraries with Bricks? Maybe you can share the code you are currently using …
This might actually be a good feature request to submit to the idea board: Ideas – Bricks
Hi Thomas,
thanks for the reply. The request is already on the idea board and complements this request (page loading progress) very well.
The implementation (adding the necessary IDs or data-attributes etc) is straight forward and the first page load works fine, but when moving to another page, it’s hard to call the appropriate bricks js. I’ll take a look at bricks 1.3.4 beta soon and give it another try. If i can get this to work, i’ll share my code of course.
I keep you updated 
Btw., what do you personally prefer? CSS Transitions like with Swup or “more enhanced” javascript transitions / animations with something like gsap or comparable libraries?
Hi Thomas,
i got swup working (with inline styles, external files doesn’t work at the moment - maybe i’ll check that later), but there are a lot of pitfalls on the way which for the most part do not relate specifically to bricks, but to the way Single Page Applications (like Swup or Barba) work, like:
Body Classes won’t update
This can easily be solved with the swup body class plugin.
Head Styles / Scripts won’t load
This can be solved with the swup head plugin.
Admin Bar doesn’t update
This is more complicated, so i decided to run swup only when there is no admin bar 
Footer JS / Scripts
This is where it get’s even more complicated, because it depends on the Javascript used on the site. Since swup removes the page reloads from site, it also removes a standard lifecycle of scripts, which come with a set of problems that those pjax-like libraries bring.
So first of all, you’ll have to create and call an init function that checks if there is any element that uses js (like .bricks-animated) and if so, call the appropriate function (bricksAnimation()) and call the function again, when the content is being replaced (this can be done with swup events). Depending on the script, it might be good to cleanup all the instances, listeners and mess when leaving a page, which can be done with another swup event that will call a cleanup function before the content is getting replaced (didn’t integrated that into my example).
To keep the example (the init function) simple, this is the code i used (if you want to cover every Javascript function, the init function will of course be a lot bigger…).
I don’t know if there is a more “elegant” way of doing this, but after all, it works and looks like this:
Custom CSS
.transition-fade {
transition: 0.8s;
opacity: 1;
transform: translateY(0);
}
html.is-animating .transition-fade {
opacity: 0;
transform: translateY(100%);
}
Body (Footer) Scripts
<script src="https://unpkg.com/swup@latest/dist/swup.min.js"></script>
<script src="https://brickswup.local/wp-content/themes/bricks-child/assets/js/SwupBodyClassPlugin.min.js"></script>
<script src="https://brickswup.local/wp-content/themes/bricks-child/assets/js/SwupHeadPlugin.min.js"></script>
<script>
const wpadminbar = document.getElementById('wpadminbar');
if(!wpadminbar) {
const options = {
containers: ["#bricks-content"],
plugins: [
new SwupBodyClassPlugin(),
new SwupHeadPlugin()
]
};
const swup = new Swup(options);
// run once
init();
// this event runs for every page view after initial load
swup.on('contentReplaced', init);
function init() {
if (document.querySelector('.bricks-animated')) {
bricksAnimation();
}
}
}
</script>Personally, I prefer CSS over JS libraries as they are more lightweight and have no dependencies (i.e. more lightweight). And are usually sufficient for most page transitions, too.
Thank you so much for all the information, and the video. Much appreciated!
If the objective is only about page transitions simply fading the HTML in and out, could be enough without using any library. In that case pjax’ing seems like an overkill.
I can see in your example that you leave the header visible during the pjax call. Which makes me think that some users might want to apply such conditions to different parts of their site. Therefore adding a whole slew of possible settings to the builder.
Not sure if the AJAX fetched HTML might cause some other problems, too. As there is so much to consider I tend towards the more simple more CSS-based page transitions I described at the beginning of this post. Thoughts?
You’re welcome!
Yeah, like i said… not an easy peasy thing to integrate and to cover all possible cases and like you said, for most people a “simple” solution (with simple transitions and without the technical stuff behind) will work as well.
I mean that divi offers page transitions, but I can’t tell you how they solved it. But a smooth transition, maybe with an optional loading progress counter or bar, would be a nice add on i think.
Okay, let’s first see how much traction the “Page transition” feature request gets (Ideas – Bricks). This one feels more like a “nice to have”, but not an essential feature. The latter are the ones that we want to focus on and execute first.
You’re right, let’s see… there are definitely more important building sites than this 
I too am a fan of CSS over JS if/when possible, and transitions are something I think Bricks will need to have, BUT ONLY if it is glass smooth. The transitions in the video (in this thread) are not smooth. Maybe because it is in the video an not seen through the browser?
Great stuff but wanted to put in two cents . . . not worth it if not glass smooth.
How did u resolve the HTML markup? I have tested by copying and modifying the page.php by changing the main id to ‘swup’ and class to ‘transition-fade’, but that didn’t work. what exactly are the criteria to make the swup.js work with bricks? it will be very helpful if u guide us with details.
Hi @timmse,
Ever since using the Swup library, the splide class (.splide) seems to be visibility: hidden.
Im only creating a basic fade
/* Swup */
.transition-fade {
opacity: 1;
transition: .5s;
}
html.is-animating .transition-fade {
opacity: 0;
}
I understand its not directly Bricks related, but do you know of any conflict or resolution? Splide is not initialized.
I’ve been hoping to use barba.js for so long/waiting for a great tutorial on using it with bricks
You’ll bump into these types of things repeatedly if using something like Swup.
The reason is… Splide (as with many things) initialises on page load. Meaning it waiting for the ‘DOMContentLoaded’ event before running the code. Swup completely removes the page load, so that event never triggers when viewing different pages.
Anything that should run on page load (which is most JS, and definitely most Bricks elements), won’t run when the user visits the next page.
You’ll need to manually run the code. I haven’t tested this, but from the code provided above there seems to be an event that runs on every page view when swup replaces the content called ‘contentReplaced’.
So you’d need to run any JS for that page, using the event.
The function name for the Bricks splide JS is ‘bricksSplide()’, you can find the functions for every Bricks element in the bricks.min.js file that is added to every page. /bricks/assets/bricks.min.js
Note that this is why Swup can be such a big problem for WP sites, as many plugins will be trying to run their code on page load, which is standard, and Swup will be stopping it all. It can be done, but unless you’re in 100% control of the site (not passing it on to somebody who may want to add plugin etc in the future) it’s likely going to be a pain, as many things will need a workaround. A lot of things will no longer work out of the box and will need manual solution.
This is also mentioned in the Swup docs, where it talks about needing to manual initialising and destroy using their own events instead of ‘DOMContentLoaded’.
Thanks for this detailed and informative breakdown!
I assume this is also the case with BarbaJS too?
barbajs is even worse! Swup has plugins that can help you with headers but barba does not. There are hacky ways of doing it but I don’t think it is worth the time and effort
can u please give a stepbystep tutorial on how to achieve swup with barba? it will be very helpful.
i have tried exact that, but, didn’t work. may be i m doingsomething wrong! so, a clearer step by step will be appreciated.