Best Practices for Using Custom Code in VWO

Some best practices to consider when using custom code to apply changes in VWO:

• We recommend using the Visual Editor to apply changes so that VWO is aware of the elements to which the changes will be applied. As a result, VWO hides these elements until the page loads, preventing the flash of original content. In this case, the elements are shown after the changes are successfully applied.
  However, if you apply the changes through custom code, VWO has no way of knowing to which elements the changes will apply. As a consequence, the original elements appear first, followed by the changes, resulting in a flicker. To resolve this, we recommend hiding those elements first, then apply the changes and finally show them. Below is a sample code snippet to demonstrate this.
  

  (CSS_SELECTOR_PATH_OF_ELEMENT) {

  visibility: hidden!important;

  }

  setTimeout(function() {

  //Make changes to CSS_SELECTOR_PATH_OF_ELEMENT

  vwo_$(CSS_SELECTOR_PATH_OF_ELEMENT).vwoCss({

  "visibility": "visible !important"

  });

  }, 500)

  view raw sampleCustomCode.js hosted with ❤ by GitHub

• If you use the setInterval() function in multiple campaigns, we recommend updating the interval id or the variable name in each. This is because if the same interval id is used in multiple campaigns running on the same URL, the changes might conflict. As a consequence, the clearInterval() function of one campaign can clear the interval of another campaign. 
  NOTE: In the example below, we used the variable name as window.vwoElInterval; you can change it to any other meaningful name.
  To ensure that a unique interval id is added for each campaign, you can use the Add setInterval function of the VWO Editor, as shown below.
  

• Avoid using the !important attribute in custom CSS code. That's because the jQuery CSS implementation does not support it. As a result, it only works with the .vwoCss() function, not .css() function. Here's an example to illustrate how you should use the !important attribute.
  
  Use the !important attribute with the .vwoCSS() function. Something like this:

  vwo_$("body > h1:nth-of-type(1)").vwoCss({

  "color": "#7f0000 !important"

  });

  view raw howToUse.js hosted with ❤ by GitHub
  Do not use the !important attribute with the .css() function like below; it won’t work.

  vwo_$("body > h1:nth-of-type(1)").css({

  "color": "#7f0000 !important"

  });

  $("body > h1:nth-of-type(1)").css({

  "color": "#7f0000 !important"

  });

  view raw howNotToUse.js hosted with ❤ by GitHub

• It is not preferable to wrap your custom code using the vwo_$() function. If you wrap any code in vwo_$(), the wrapped code runs on the DOM Ready, which would certainly lead to a delay, resulting in a flicker if the modified elements are present above the fold.

• If you use the insertAfter() and insertBefore() functions in your custom code, make sure they are available on the $/jQuery object you're using because these functions are not available in vwo_$.
  
  
• If you experience problems with changes being applied intermittently on the live website or previews, we recommend adding a console.log statement in your code to verify if the logs are correctly displayed. If the console logs appear fine, it indicates that VWO is successfully executing the code, however, there might be a problem with your custom code that needs to be checked/fixed on your end.
  In such instances, there's a possibility that the custom code executes without waiting for the appropriate elements. For example, you have wrapped the code in a DOM ready callback, expecting that the elements will be ready by then, however, the elements load after DOM ready. For cases like these, we recommend using a setInterval() method to check for the availability of the desired elements on the page. Use Add setInterval function option to embed the setInterval code block and customize it as per your requirement.
  
  NOTE: If you do not see the logs in your console, reach out to us at support@vwo.com.

• We recommend using live previews to verify your campaign changes before making it live for your audience. It allows you to validate whether the campaign changes appear as expected or not.
  
  NOTE: Before viewing the live previews, make sure there are no debug cookies present. If there are any, please clear them.
• If you use segmentation in your campaign, we recommend you verify the segment conditions using live previews to simulate your audience's environment. You can do this by disabling the Ignore campaign targeting conditions in previews option, which looks for segmentation conditions and only shows changes when the segmentation conditions are met.
  The previews will not display the changes until the segmentation conditions are met. Instead, you would see a warning message, as shown in the screenshot below. This helps you determine whether the changes didn't apply due to campaign settings or campaign code.