Sage 9 - external Js not defined

I’m trying to install external JS in sage 9

I’ve added with yarn and linked

import ‘barba.js/dist/barba.min’;

but when calling Barba.Pjax.start(); I just get a Barba not defined error

Have I installed the external JS incorrectly? how should i go about doing this in sage 9?

2 Likes

You probably need to define it here:

1 Like

Unless you’re pulling it in externally (it doesn’t look like you are, judging by your source), in which case you’d do that here:

1 Like

Not quite sure I follow sorry!

If I just include the script with from the cdn:
https://cdnjs.cloudflare.com/ajax/libs/barba.js/1.0.0/barba.min.js

It seems to works perfectly with no Barba not defined errors.

But when I do yarn add barba.js then include at the top of main.js with

import 'barba.js/dist/barba.min';

when I try to call Barba I just get the barba is not defined error.

can you explain about defining it in the Conifg? I was following the instructions here on including external scripts:

1 Like

I guess you already solved this problem but for others coming to this link.

Use common.js

import Barba from ‘barba.js/dist/barba.min’

That should solve the issue.

Not tried on Barba but had similar issue with other external js.

I too am having the identical issue Jake is, I added barba with yarn

on main.js I added import 'barba.js/dist/barba.min';

The yarn build works fine until I add Barba.Pjax.start(); to /resources/assets/scripts/routes/common.js then I get

Module build failed: Module failed because of a eslint error.
error ‘Barba’ is not defined no-undef

Per QWp6t I tried adding to webpack.config.js

so far nothing is working, any advice would be great

OK, happened to try this today and also remembered there was a thread about this.

Here’s the working solution.

Add via yarn

yarn add barba.ja

main.js

import 'barba.js/dist/barba.min';

webpack.config.js

new webpack.ProvidePlugin({
  $: 'jquery',
  jQuery: 'jquery',
  'window.jQuery': 'jquery',
  Popper: 'popper.js/dist/umd/popper.js',
  Barba: 'barba.js/dist/barba.min',
}),

routes/common.js

/* eslint-disable */
Barba.Pjax.start();
/* eslint-enable */

Works for me!

3 Likes

I took a slightly different (simpler?) route:

Add via Yarn

yarn add barba.js --dev

routes/common.js

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…

6 Likes

Much better and makes total sense :nerd_face:

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?

Hi @dghez,

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?

It should look something like this:

"devDependencies": {
    ...
    "barba.js": "^1.0.0",
    ...
}

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. :slight_smile:
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?

Great, glad you got it working! :slight_smile:

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:

Good luck!

I’ve modified the way “routes” are loaded on my theme and changed them to ‘views’ (trying to follow barba.js nomenclature):

image

View example:

image

Obs: I did this almost a year ago, probably would done somethings different now.

3 Likes

Muito obrigado Christian :slight_smile:

It’s really helpful to see how you’ve handled this! To declare the namespace for Barba, are you still doing this (below)?

1 Like

Yep! Part of the same theme :wink:

1 Like

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 :thinking:

EDIT: doesn’t matter anymore. I’m moving to a different structure as @kaisermann suggested :slight_smile:

1 Like

This makes absolutely sense. That’s so clever. Awesome work :slight_smile: 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 :slight_smile:

1 Like

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).

image

1 Like

Cool, make sense. :slight_smile:
Btw thanks, you made my day with the previous setup :heart:

1 Like