import Barba from 'barba.js/dist/barba.min';
export default {
init() {
// JavaScript to be fired on all pages
Barba.Pjax.start();
},
finalize() {
// JavaScript to be fired on all pages, after page specific JS is fired
},
};
That’s my whole routes/common.js file but you can see it’s just 2 lines added to it. Since I am importing/declaring then using Barba in the same place, there’s no need to disable the linting…
Hey @Stephen I did exactly the same as you did but it doesn’t work for me. My common.js file is the same, I tried even the copy-paste technique to be sure ahah. Even if I go to the console and enter Barba.Pjax.start(); I get Barba is not defined.
Any idea?
That’s strange - it sounds like the library isn’t being included in the final JS bundle. Can you confirm that the barba.js folder exists inside your node_modules directory in the theme folder? Inside that folder you should see a dist folder with barba.min.js inside it.
Can you also see that barba.js is referenced in your theme’s package.json file in the devDependencies section?
Lastly, did you re-run yarn start or yarn build:production after making these changes? If you do a production build, you can examine the JS file it builds and inside that you should see some references to barba…
I assume you’re also using the latest Sage 9.0.0-beta.4 version of the theme? Let us know any other relevant details like your OS and development stack…
Hey @Stephen! Thanks for the reply, I had the same problem and I got it solved thanks to you. I think it was a cache problem, or something similar. After some hard refresh everything starts working.
Btw what I would like to know is how are you currently manage the js lifecycles. As you probably notice the site becomes something like an web-app so the js lifecycle is different. I found some useful explanation on the author’s site where it talks about Views but in this case the structure of the js will become super-nested, isn’t it? I mean, Barba needs to be included in common.js and inside the init() function right? So after initialized everything needs to be nested into this so it becomes something like common.js -> init() -> Barba init -> Barba views so everything will go in the common.js?
EDIT: As far my knowledge are poor in webpack (so commonjs amd etc) I noticed that if I use Barba.BaseView.extend into another page & related js file (like aboutUs.js) everything should be fine if nested into the export module function. Am I right?
You’re right about it being a challenge to handle the JS lifecycle. On my current project, I’ve actually temporarily disabled Barba.js because it was causing a lot of problems and it isn’t a major priority to have it working for the final site.
It’s not really a fault of Barba.js but rather the rest of the WordPress setup - this site has some Revolution Sliders and they inject inline script blocks into the HTML but they never get executed when loaded via AJAX. There are probably ways around it but I’m hoping to convince everyone that we don’t actually need this monster plugin… The other problem I had was with Elementor because it has page-specific CSS files that it generates and these would need to be injected or embedded directly into the page content.
So for now Barba.js is on the back-burner but I would like to get it working at some point. I read the section about using Views and what you’re saying should be fine - as long as the Barba object is properly imported and in an available scope, you should be able to use it in those other files. There are probably several ways you could structure it but on first look, using the Sage routing seems to make sense.
Since I haven’t gone deep enough into using Barba.js, I’m not the best one to answer these questions but you could try reaching out to @kaisermann or @mikespainhower since they have both used Barba.js on sites they’ve developed…
On the topic of Webpack, this might help to understand how it all fits together:
Actually I tried this too but this doesn’t work.
I did exactly the same but I still get errors. The only way to make it works is to do import Barba from 'barba.js/dist/barba.min' in every file where I need to write something Barba related (common, about etc ) but in this way I don’t understand why I need to import it in the main.js
EDIT: doesn’t matter anymore. I’m moving to a different structure as @kaisermann suggested
This makes absolutely sense. That’s so clever. Awesome work I’ll take inspiration from this to manage my stuff.
Btw what I don’t understand is how do you manage the “common” js. I see you call common() on document ready and everything is fine for the first time but when the user change page it won’t fired anymore. I checked you view example and you don’t include anything related to common js so you’ll do in another way.
EDIT: Actually I think you do it using BarbaOnEveryPage that is fired with the dispatcher.on('newPageReady') but in this way I don’t understand what is “common” used for
I reckon ‘common.js’ was a very bad name decision in this specific case. It’s a file loaded once whenever someone access the website. I use it to keep track of some elements between pages and other website-specific thingies (again, would do a lot of things differently nowadays hehe).
Hi all - reviving this thread. Just launched my firm’s new portfolio site, built on Sage 9, and trying to implement Barba.js - but having quite a bit of confusion. Does anyone have more details on how to implement it and get it playing nicely with Sage 9’s JS routing? I can successfully install it and get it transitioning between pages, but my main issues seems to be updating the body classes for each page, and get the page-specific JS to work. @kaisermann - I can see the idea behind your implementation, but am a bit unclear on how to get started transitioning to it. Also, where have people succesfully placed the barba-wrapper and container divs? Thanks for any assistance!
Could not find a declaration file for module ‘swiper/dist/js/swiper.min’. ‘/Users/john/www/project-name/wp-content/themes/project-name/node_modules/swiper/dist/js/swiper.min.js’ implicitly has an ‘any’ type.
@dangelion can you share your actual code that gives this warning? This was quite a long time ago so I don’t recall exactly why I was referencing that dist folder in the import statement but sometimes it is necessary if you need a specific file and/or the package doesn’t declare the “main” file inside its package.json.
I see you’ve got swiper.min in your message but you shouldn’t need to pull in the minified version because the final bundle will get minified by webpack when you run yarn build:production
