00:00:14.150
Hi everyone! My name is Nate, and I work at a search retargeting company in the city called Magnetic. We're hiring, so come talk to me afterward; that's my shameless plug. Now, let's talk about third-party JavaScript.
00:00:29.310
All of you kind of know the general concept of third-party JavaScript. You've seen the like button, Twitter widget, Google Analytics, Olark, and tons of advertisements. If you actually inspect the DOM on many pages, you'll see it's polluted with content, and there’s so much going on that it can be difficult to navigate. So, let's take a look at how these third-party JavaScripts function.
00:00:41.010
Generally, these scripts have two parts: the embed code and the logic code. If you've used Google Analytics before, you're familiar with the little code clients put in their websites, which usually loads something more substantial containing all the logic. We want this embed code to be small; you don't want to overwhelm your client with a huge embed code. The logic code is the 'meat' of what we want the code to do. Most of the time, this is where the biggest problems arise, particularly concerning the same-origin policy. However, we will not delve into that today.
00:01:10.590
Let’s pretend that our logic JavaScript looks something like this: we’ll create a text node and append it to the page's body. This is a significant starting point. Now, how do we go about testing this? We give the embed code to the client, and ideally, we want to ensure that it will work perfectly on their page.
00:01:55.470
However, the environment where our code is running can be unpredictable. We can set up our test page, for instance, creating a view in Rails where we place the embed code. We can run tests using Capybara to visit our test page and expect it to have specific content. This approach allows us to ensure that our embed code functions as intended, providing us confidence in the stability of our features.
00:02:25.360
Now, while it's quite satisfying to see our tests pass, we still face uncertainty about how the code will behave in the client's environment. This can be particularly troubling, especially if you are in a startup situation where a lot is at stake. If we hand over this code to the client and it breaks their page, that's not an outcome anyone wants. You’re often left with an uncomfortable feeling, wondering if the JavaScript will work correctly once it's live.
00:03:39.830
One idea that might come to mind is to go to the client's page, open the Chrome Developer Console, and paste our JavaScript code to embed it live. However, this often leads to issues like syntax errors or other problems that indicate our JavaScript is not executing as it should. Even if our tests pass in the controlled environment, we must consider the bigger picture of how it will function on the client's actual page.
00:04:40.080
A core issue with third-party JavaScripts is that most testing doesn't account for different environments. Since each JavaScript may interact differently based on the libraries a client is using, we have to consider potential conflicts, such as competing versions of jQuery. To tackle these issues, we need to ensure that our design accommodates various scenarios and library clashes.
00:05:14.440
One potential solution is to set up a proxy server that can allow us to intercept browser requests. By listening for client page responses through this proxy, we can inject our JavaScript directly into the pages on which it will run. This would allow us to simulate our JavaScript running on the actual client site, providing a level of confidence in our code's functionality.
00:06:34.060
Let's briefly look at how to create a proxy server in Ruby. Using WEBrick, we can create a simple server to listen for requests and inject JavaScript into HTML responses. It’s important to ensure that the response content type is HTML and that it's from our specified host before we inject our script. This technique allows us to give the impression that the JavaScript is running directly on the client’s page, enhancing both our confidence and our clients' experience.
00:07:45.100
Once you've established the proxy server, you can register it with Capybara as a custom driver, directing your tests to interact with it instead of the actual client site. This approach also facilitates testing across various environments, proving useful for debugging in Internet Explorer or other browsers. By configuring your tests correctly, they can run seamlessly in this setup.
00:09:15.110
Having effectively simulated our JavaScript running on the client site, we can ensure everything works as intended during tests. This not only helps with confidence in our JavaScript deployment but also allows for effective demonstration to clients of how their pages can look and function with our scripts.
00:10:10.670
As a side note, using techniques like this can be beneficial for product demos without requiring clients to perform integrations beforehand. After all, it provides an opportunity to showcase how your JavaScript enhances their site with minimum fuss. Furthermore, using tools like PhantomJS can extend functionalities, simplifying the task of managing real-time responses.
00:11:12.350
In conclusion, when developing third-party JavaScript, remember to test in environments as closely resembling the client's setup as possible. You should also think critically about potential issues that could arise, such as API downtime or improper script placements. I hope this technique will empower you to catch edge cases and get the most out of your testing efforts.
00:12:00.339
Thank you!
