Removal of Jquery Dependency


Userlevel 6
  • Former Unbouncer
  • 198 replies

UPDATE [April 2, 2019]: This change has been deployed! Unbounce is no longer dependent on jQuery for form submissions 🙂


UPDATE [April 1, 2019]: The code change to remove our dependency on jQuery will be released this coming Wednesday, April 3rd.


UPDATE [March 28, 2019]: This release has been pushed back to later in the week to allow time to address some issues with a couple of community workarounds that would have broken with this update. This deploy will not be going out today (Monday, March 25th). Updates will be posted here when a new release date is determined.


Hi everyone, some exciting news to share 👋

Some of you have commented in the community about the use of jQuery on Unbounce landing pages and today we’re here to share an update (jQuery is a Javascript library we used to power Unbounce’s form submissions). As of Monday, March 25th, we’ll be rolling out an update to remove this dependency.

What does this mean for you?

Form Improvements
By removing the dependency on jQuery, your Unbounce forms will leverage your visitor’s web browser to power any form validation errors. This means a much deserved facelift to form errors and a more robust method for alerting visitors to any issues with their forms. Basically, any form validation errors will look a lot better.

This change will allow for faster iteration and a more scalable code base that will enable us to make future updates more efficiently and with less risk. Instead of using an older version of jQuery (1.4.2) to handle submissions, Unbounce forms will instead use vanilla javascript moving forward.

FAQ

Will this impact custom code on my page that uses jQuery?
We’ve tested to make sure that Unbounce features continue to function as expected, however, since there’s no way for us to test all custom scripts, there’s a chance that some custom code may be impacted. We rely on the feedback here in the community, so if you notice your custom code functioning differently, please let me know and I will relay it to our product team. The removal of the dependency on jQuery has also been tested against the majority of community tips and scripts (https://community.unbounce.com/c/unbounce-tips-and-scripts) so if you’re using any of those, you should be all good. We recommend double checking your custom code just to be sure.

Will workarounds from the community using jQuery still function?
Popular workarounds involving custom validation rules and messages will still function as expected as will the workaround to execute code on form submission. Despite thorough testing however there is still a chance that fully custom coded solutions involving form submission may be impacted as we cannot account for 100% of custom code solutions when testing. We recommend double checking your custom code just to be sure.

Is Unbounce removing jQuery from my already published pages? What if I have other functionality that depends on jQuery?
Not to worry – this update only affects the use of jQuery for form submissions. If jQuery is included on your page with either custom code or by selecting the 1.4.2 box in the builder, it will continue to load on live pages as before. If you are intentionally including jQuery on an Unbounce page it will continue to load as expected.

Native Chrome Validation Error

image-20190208-012358

Want to take your Unbounce landing pages, popups, and sticky bars to the next level?

:spinbounce: Check out the Ultimate List of Unbounce Tips, Scripts & Hacks


37 replies

Userlevel 7
Badge +1

Woo! Tagging @Phillip here, this is something he’s been championing for a while here in the community. :clap:

You stated:

Popular workarounds involving custom validation rules and messages will still function as expected

Does this mean that any custom validation rules that we’re injecting via lp.jQuery.validator.addMethod should still function?

What about the usage of the popular Multi-Step Form Script since it too relies on the existing validation to properly handle “validation by step”? Should that still function as expected?

Many of my clients’ pages rely on each of these so I have a real worry that this change will break many of their forms.

Will this allow us to disallow submissions from certain domains for example?

Hey @foundsm.nicholas,

I can confirm that both of those workarounds will continue to work. Here are two demo pages:

  1. Custom validation
  2. Multi-step form

Hi @Brian_Burns,

Thanks for the reply. It looks like the multi-step script that’s in use in your example is different than the one shared in this thread. Would you mind sharing the updated script so that we can test it with our forms?

@Brian_Burns That multipage script is a seriously simple test case.

Firstly it’s throwing many errors about fields not being focusable. ((second time I loaded it threw a whole new batch of errors, third time different warnings))
It appears that the shim you’re applying isn’t taking into account that it maybe trying to focus on a field that isn’t on the current page of the multipage form.

Secondly on the test account we had @Rob setup for our use we are having issues with validation of multiple fields on the same page. It appears that running lp.jQuery(validateArr.join()).valid(); Where validateArr is an array containing multiple fields to run validation against is only running the first validation and then returning true.

So are you able to modify the example page you have so there are multiple fields on each page and test that. And can I reiterate the request for you to share the link to the multipage script you use in this example?

Figured it might be an idea to try this avoiding the Shims you’ve put in place to make older pages work in this new system. The following is the older function we were using for page specific validation and the quick test function I put together… it appears to be working with the first page I tested this on… Going to continue testing…

 var isValidOld = function(page) {
    var fieldsArr = pages[page].split(',');
    var validateArr = [];
    for (var i = 0; i < fieldsArr.length; i++) {
        var x = fieldsArr[i].replace(/(#container_)/g, '').trim();
        validateArr.push('[name="' + x + '"]');
    }
    return lp.jQuery(validateArr.join()).valid();
};

var isValid = function(page) {
    var fieldsArr = pages[page].split(',');
    for (var i = 0; i < fieldsArr.length; i++) {
      var x = fieldsArr[i].replace(/(#container_)/g, '').trim();
      if (!document.getElementById(x).reportValidity()){ return false; }
    }
    return true;
};

[edit: Doesn’t appear to work for radio groups]

Userlevel 7
Badge +1

Hey @TimothyDO and @foundsm.nicholas!

Sorry for the radio silence, we shared this update near the end of the day on Friday and many of us weren’t able to respond on the weekend.

Just wanted to keep you both in the loop, we’re currently evaluating the best way to roll out these changes. Ultimately, we want to avoid as much negative impact as possible, so thank you for providing so much context here. Our devs will take a look at this thread and come up with an update for you. @Rob will be the ringleader for how we proceed, and he sits right next to me so that will make it easier for me to keep you all updated.

If this means pushing back the release by a couple days, then that’s what we’ll do. Stay tuned here, we’ll have an update for you today.

-Jess

Hi Jess, We’ve been in regular communication with both our account manager and Rob over this. I don’t think our being on GMT helps with communications with this though. That email about the release was around 9:40pm GMT on a Friday suggesting a Monday release… there would have been radio silence from our end too 😉

I was kinda hoping that the issue with the shim would be fixed so that we wouldn’t need to change every single page we host.
Rob was kind enough to setup a test account for us so we could test the various scripts we make use of.
I have put together a working equivalent of the isValid function making use of the reportValidity method you guys are moving to.
This is our isValid for checking if a selection of field is valid so that you can make use of a next button to switch between different pages with a portion of the total number of fields in the form. There is both the original function and the newer function here so I am hoping this can help in your debugging of the Shim. 😉

I know you’re probably not even through your first coffee yet and your early reply is appreciated but it would be great if we could know what is going on with this before 10:30am PDT (5:30pm GMT).

 var isValidOld = function(page) {
    var fieldsArr = pages[page].split(',');
    var validateArr = [];
    for (var i = 0; i < fieldsArr.length; i++) {
        var x = fieldsArr[i].replace(/(#container_)/g, '').trim();
        validateArr.push('[name="' + x + '"]');
    }
    return lp.jQuery(validateArr.join()).valid();
};

var isValid = function(page) {
    var fieldsArr = pages[page].split(',');
    for (var i = 0; i < fieldsArr.length; i++) {
      var x = fieldsArr[i].replace(/(#container_)/g, '').trim();
      console.log(x);
      if (typeof document.getElementById('#group_'+x) !== 'undefined') {
        var y = document.getElementsByName(x);
        if (!y[0].reportValidity()) return false;
      } else if (!document.getElementById(x).reportValidity()){ 
        console.log("fail:"+x)
        return false; 
      }
    }
    return true;
};

Hey @foundsm.nicholas,

Apologies. I thought you were referring to a different multi-form script and didn’t follow the link you provided. We are looking into your issue today.

Brian

Userlevel 7
Badge +1

Hi @TimothyDO, Rob told me he’s sent you an email to discuss this further, I think it would be best if you both discuss your particular situation in a separate thread. I’d like to ensure that no updates get buried in this thread.

Rob will be updating here with more info 🙂

Thanks @Jess I did remove my post when we (myself and rob) started chatting over email on this. Given him a detailed explanation of my findings for the day.
Might still be an idea to post the amended date for this though 😉

WOOT, WOOT!!! 🤩

Awesome! What kinds of feature updates do you guys plan on rolling out to the forms moving forward?

Is there an updated timeline on when this is getting rolled out?

Userlevel 6

Hi @mdunsterville, we are going to be releasing this on Wednesday this week (April 3rd) 🙂

Userlevel 5
Badge +2

Thank you @Rob!

Userlevel 5
Badge +4

Hello !

It looks like some of my LP have already received the removal of Jquery.
but i’m having trouble for two reasons:

  1. i use a script to translate the error message in french. Even for LP where the Jquery hasn’t been removed there is a problem with the encoding of the special characters. here is an example

52

  1. I’m using the multi-step script in almost all my LP now and as you can see on the picture above the error messages appear twice.

here is the LP i’m talking about (still a work in progress 🙂 ) https://recevoir.mes-devis-pratiques.fr/securdouche/a.html

and here is a LP without the removal where the translation script is also messed up since today or yesterday i don’t know : https://www.eau-pure.fr/adoucisseur-sfte/

Maybe the update is not complete but if you can keep an eye on this

thanks

Userlevel 7
Badge +1

I’m definitely keeping an eye on this! Thanks for bringing this to our attention @julien_level!

Userlevel 5
Badge +4

hello,

I found a solution for the second problem in the multistep form script.
you have to remove this part in the JS of this script:

//add error span
errorSpan.classList.add('hide');
errorSpan.style.color = '#FFFFFF';
errorSpan.style.position = 'absolute';
var labelHeight;
if(allFields[0].querySelector('label')){
labelHeight = allFields[0].querySelector('label').clientHeight;
}else {
labelHeight = 35;
}
errorSpan.style.top = '-'+labelHeight+'px';  
formContainer.appendChild(errorSpan);

For the special characters, i have removed them from now so it looks better but it has to be a temporary solution.

Userlevel 5
Badge +4

I think i’ve lost almost a day of trafic.

I’ve found that on a lot of my LP (and all variant) that people couldn’t add their phone number.
It looks like by default, all phone fields have been set to “validate phone number as american” while not being activate in the form parameters…
it took quite some time to change all form to set them up to 'validate phone number as generic".

I also had to desactivate the “custom validation” script that helped me make sure that people were entering french number (10 digits) as it doesn’t look like it’s working anymore.

I really love Unbounce but i think it’s time to really update the form parts to give more options naturally and depends less on script.

update : Wow i just tried my LP in Firefox and i get a white page after completing the form…
this is getting serious, i have to stop buying trafic for now.
here is my LP : https://www.eau-pure.fr/adoucisseur-sfte/

Hey Julien,

We have a fix for the first issue coming out this morning and are looking into your second issue today.

While you’re looking at the telephone field it’s not assigning type=“tel” either. So our custom validation built for this new version doesn’t recognise telephone fields… @Brian_Burns

Userlevel 5
Badge +4

Thanks @Brian,

Other stuff i’ve noticed:

  1. When i go to “view leads” in unbounce i now have two “Telephone” rows with identical data in it. I can’t remember if it was already there before and it has an impact on my pages.

2.When i test my form with my computer and the computer of someone working with me, the lead will go into unbounce (view lead) and when i click on the lead to see if it was sent by the webhook it say yes. But i have nothin in my CRM… Strangely leads coming from outside are getting there normaly

I don’t believe these issues are related to this release. Your leads seem to have had the duplicate telephone rows for quite some time. As to the second issue, I can only speculate that it may be something to do with a firewall if it’s only affecting leads from within your company.

Reply