Uncaught SyntaxError after activating first time

@lydenyardley Thanks for reporting the issue

After analyzing your site, I found a code that conflicts with Flying Pages. The code :

<script>/* from https://usefulangle.com/post/108/javascript-detecting-element-gets-fixed-in-css-position-sticky */
var observer = new IntersectionObserver(function(entries) {
	// no intersection with screen
	if(entries[0].intersectionRatio === 0)
		document.querySelector("header").classList.add("scrolled");
	// fully intersects with screen
	else if(entries[0].intersectionRatio === 1)
		document.querySelector("header").classList.remove("scrolled");
}, { threshold: [0,1] });

observer.observe(document.querySelector("#scroll-detector"));</script>

The error is because observer is already declared. You can fix it by renaming a variable. Here is the updated code if you want:

<script>/* from https://usefulangle.com/post/108/javascript-detecting-element-gets-fixed-in-css-position-sticky */
var scrollObserver = new IntersectionObserver(function(entries) {
	// no intersection with screen
	if(entries[0].intersectionRatio === 0)
		document.querySelector("header").classList.add("scrolled");
	// fully intersects with screen
	else if(entries[0].intersectionRatio === 1)
		document.querySelector("header").classList.remove("scrolled");
}, { threshold: [0,1] });

scrollObserver.observe(document.querySelector("#scroll-detector"));</script>

Pls try it and let me know

• This reply was modified 5 years, 2 months ago by Gijo Varghese.

I’ve also renamed the observer variable in Flying Pages to prevent conflicts with others. Just update to v2.0.9

Hey Gijo, why aren’t you using an IFFE to remove any conflicts at all. Shouldn’t be using global space anyways?

@pcfreak30 initially it was like that. But Swift Performance adds a try-catch (when you combine scripts) around our lib and function which removes the scopes and causes errors. That’s why I had to go in this way

IMHO, I think that should be something Swift Performance should be solving as the workaround by you I think will cause more problems in the long run.

@pcfreak30 I’ll definitely consider this. Will also contact Swift Performance guys if there is a proper way to solve this

Besides if they did that, how are things in webpack and es6 stuff handled?

@pcfreak30 I didn’t get. Do you mean browser support?

No, the fact webpack/es6 stuff is bundling a ton of anonymous functions and IFFE’s together, that the logic/heuristics Swift Performance use would wreak havoc.

@pcfreak30 most of the plugins/scripts use a single js file or inline script. In the case of Flying Pages, we’ve both to get it to work. Something like this:

<script src="/flying-pages.min.js"></script>
<script>flyingPages({...options})</script>

If we add a try-catch or IIFE inside flying-pages.min.js, then it won’t be able to access beneath it

You missed my point. I am saying the fact that a lot of applications/scripts use ES6 code which is basically webpack. So if they are doing this to your code, they would likely nuke any bundled js module or application, custom or public. So overall they are doing something that’s a bad idea from what I know so far.

@pcfreak30 Got it.

I just talked to Swift Performance guys. They’re removing try-catch! The update will be released probably tomorrow ??

Hi @gijo

Thanks so much for digging into this and providing various responses and effort to resolve. I implemented the observer tweak you provided, and updated your plugin successfully.

The console log errors have now gone away, but how can I verify that the plugin is preloading the pages behind links? In my eyeball testing, I can’t notice much difference… and can’t see anything happening in DevTools. But I may simply not be looking in the right places…?

What do you think?

@lydenyardley Can you share the url of your site so that I can check?

Sure – same is in my OP – https://yardley.me