Avoiding jQuery conflicts

[jthmk]

I created a hype project with physics that uses jQuery Collision - Everything was working great within Hype and when published (including iframes) - however when I embedded the project into a Webflow div the collision stopped firing.

Through a process of elimination I figured out that collision plug-in doesn't work on the newer version of jQuery (which Webflow uses)

So by adding the older jQuery in Webflow it all works - and there's no other errors (yet) in the console. I'm still pretty green with code, however, I know that it's not good practice to use 2 versions of jQuery.

My question: If I include the earlier version of jQuery min within a function in the hype document itself e.g. 'on prepare for display' rather than the head tag - my theory is that this is nested deep within Hype's js and would't be able to mess with anything on the parent Webflow document - is this thinking correct, and is there any disadvantage?

I realise it would probably be easier to use a different plugin for collision that will work with latest jQuery but it took me so long to get this working that if this workaround is ok I'd rather go with it. Or should I just iframe it into Webflow and be done?

Thanks in advance.

[MaxZieb (Loves Hype)]

If you embed it in Webflow without an iFrame you are not including jQuery as head HTML is not transferring.
In that case you would be using the jQuery version provided by Webflow or would need to upgrade it on the Webflow side (if possible)

If you are using Hype inside of an iFrame you will be loading anything that is referred in head and you are loading jQuery twice… but then again you need to do that as the iFrame runs in its own context and doesn’t share resources with its parent.

[jthmk]

@MaxZieb

If you embed it in Webflow without an iFrame you are not including jQuery as head HTML is not transferring.
In that case you would be using the jQuery version provided by Webflow or would need to upgrade it on the Webflow side (if possible)

Thanks Max,

So everything within the _hype_generated_script.js (including an entire jQuery min file) is essentially sandboxed and can't affect the parent HTML page that loads a different jQuery version?

[MaxZieb (Loves Hype)]

_hype_generated_script.js doesn't contain jQuery if you added it to your resources folder. It only is added to your resources folder … the association with your Hype file happens in head HTML. Therefor it only loads if you include Head HTML content. So, depending if you copy and paste it over or not you won't be loading it.… on the other hand if you embed the main HTML file in an iFrame you are loading everything that is in there, but in that case it is sandboxed in the iFrame.

[MarkHunte]

Wondering if it would work by putting the minefield code directly in an hype function and aliasing to that. Load on Prepare for display and make calls using the alias ( vague idea )

Should have read the thread a bit better, indeed it seems you are putting the code in an Hype function.

i.e coping the library files code and placing it in an hype function..

---

---

Not being familiar with Webflow or how that works but may be worth a try?

Two possible things you can do that may help with clashes and avoid iFrames

With the JQuery library code inside a Hype function and running in a Prepare to Display function.

You can add your own alias to the end of the Jquery function code.

I.e

window.jQuery = window.myjQuery = jQuery

---

We are effectively redirecting $ symbol with myjQuery and redirecting jQuery back through myjQuery

If you use either $ symbol or jQuery it will run but should be redirected through myjQuery

---

or

---

You can add to the end of the Jquery function code.

window.myjQuery = jQuery.noConflict();

We are effectively replacing the $ symbol with myjQuery

If you use the $ symbol it will give an error.

We are also redirecting jQuery back through myjQuery

If in code you use jQuery name this should still work.

But you should use the new alias name instead myjQuery

---

In both options you should then be able to run code like so.

 var txt = "";
  txt += "Width: " +  myjQuery("#div1").width() + "</br>";
  txt += "Height: " +  myjQuery("#div1").height();
   myjQuery("#div1").html(txt);

See next post for update

[MarkHunte]

An update to my post above.

I think the second method works better.

Here is an example.

In the head is a CDN to a newer version of JQuery (1.12.2) than what is in the Hype function (1.8.3)

We have two boxes that when clicked will run some JQuery code. which gives the boxes dimensions and JQuery Version number.

Box 1 will run the version declared in the hype function and using the

window.myjQuery = jQuery.noConflict();

In our Hype functions we use myJQuery to call that version.

Box 2 will run some JQuery in the Head that will use the CDN JQuery.

In the head we use a $ symbol to call to the CDN version.

One caveat is if the JQuery name is used any where then the Hype version will be used.

myJquery.hype.zip (54.1 KB)

[jthmk]

Hi Mark, this is exactly what I’m doing/ looking for.

There are currently no conflicts or issues using both versions of jQuery directly in the parent page head - but it’s not good practice to run 2 versions and I want to safeguard against any potential conflicts.

So my thinking was that by including the jQuery library within the Hype ‘prepare for display’ function, it would all be nested inside the _hype_generated_script.js and so maybe any other jQuery on the parent page would all be done using it’s own version in the head and it would never see the additional jQuery library hiding within the _hype_generated_script.js

But I don’t know enough about the hierarchy or the rules of javascript’s spacetime, I know it executes top down but does it detour through the hype _hype_generated_script.js or does it sidestep it

I did see jQuery.noConflict(); but wasn’t sure how to implement it in this context so the example you’ve provided is really helpful, I will try and get my Hype document to work the same way. Thank you so much.

So in effect, we are not just trying to hide the 2nd version of jQuery from the parent we are giving it an "identity disguise" so even if the parent did see, it won't recognise it.

@MarkHunte

One caveat is if the JQuery name is used any where then the Hype version will be used.

Can you just elaborate on this? Is this just in your example because of the CDN in the head. My Hype document will only have the "myJQuery" and Webflow will use its own version in its head. Or did you mean if JQuery is used instead of the alias $ in either place it would default to "myJQuery" version?

Thanks again, really appreciate the help guys

[MarkHunte]

@jthmk

But I don’t know enough about the hierarchy or the rules of javascript’s spacetime, I know it executes top down but does it detour through the hype _hype_generated_script.js or does it sidestep it

JS including the hype generated script will load in order top down.
This is why it is important to have some linked JS libraries added before others so the later ones can use previously loaded ones.

@jthmk

So in effect, we are not just trying to hide the 2nd version of jQuery from the parent we are giving it an "identity disguise" so even if the parent did see, it won't recognise it.

Yes this is the intent

@jthmk

mean if JQuery is used instead of the alias $ in either place it would default to "myJQuery" version?

Hi yes, this looks like what it will do

Remember @MaxZieb points regarding iframes is also relevant.
If you are using iframes then you should not need to worry about conflicts and just carry on as you are

[MaxZieb (Loves Hype)]

Probably, you can also go to the root of the problem and eliminate jQuery from your Hype project entirely because Hype includes the Matter library for physics, and with a tiny little bit of code you can actually enable collision detection see the following link:

Collision detection using the physics engine (Matter.js)

This is an easy way to detect collisions and get the members involved in the collision. This simple example doesn’t deregister the event handler so keep that in mind when switching scenes. Code (reduced to essentials): // Fetch physics engine for our hypeDocument var hypeDocElm = document.getElementById(hypeDocument.documentId()); var engine = hypeDocument.getElementProperty(hypeDocElm, 'physics-engine') // Event listener Matter.Events.on(engine, 'collisionStart', function(event)…

[jthmk]

Hi Max,

Thanks for this, I did see this version, it looks great and it would be much more elegant but the detection seems to be between static and dynamic elements and I haven't been successful in separating it out i.e. If ball 1 hits static element x do this but if it hits static element y do this.

Is there anyway to manipulate this code so multiple different detections are between the element IDs?

[MaxZieb (Loves Hype)]

You have aElm and bElm … those are the two participants in a collision. You can use some identification like class names or data attribute to identify them and trigger an action.

If you want action using a data attribute per item callbacks and don’t mind a dependency you can also use Hype Action Event as it supports collision events as well.

[jthmk]

Hi Max,

I looked at that example again and was able to figure out how to get it working how I want, it's a much better way to implement it. Thank you. I marked Mark's answer as the solution in the thread because it did answer the original question and it's still really useful to know how to do this. But both answers are amazing, appreciate all the contributions.