JavaScript Function Redefinition
“ Want to reduce flickers while performing A/B tests? Here is an ingenious solution to all your flicker problems”
JavaScript is a very unique language. If you ask me, I completely love it. Because it gives me the freedom to create and innovate without being too robust. I have been creating numerous A/B ( don’t know what A/B tests are? More about it here ) tests for a year, and after creating these I have perfected my art to solve really tough problems without even touching the codebase.
The Problem
One of the major problems front-end developers face regarding the A/B test is “Flickers”. They are the absolute mood killers. No matter how engaging UI you create to entice the user to buy stuff with your A/B test, if there is a flicker there is a possibility the revenue is going to drop. As it does not give a terrific user experience.
The Use Case
Let’s try to understand this with a use case. Suppose there is a purchase button at the bottom of the page. And your hypothesis is: moving that button to the top in the navbar will be compelling for the user. So that the user would purchase your product. Let's look at the possible approaches with which you can achieve this.
Traditional Approach
If you want to perform any operation on an HTML Node it should be present on the DOM. Traditionally we use a timmer which checks after a certain amount of time if the element has appeared on the DOM. And then we make our changes. But this approach is vulnerable to flickers.
The Solution
Let’s look at the one-stop solution for all major flicker problems. In your front-end application, there is a function that is rendering a button on the DOM. What we want to do is redefine the function and first call the original functionality and then call our code.
When the application’s codebase calls the renderButton function. As we have redefined the function, the new function will be called. And that’s where the magic happens.
Why is this Appropriate?
Ideally, it is not recommended to perform function redefinition in your codebase. Because it can cause a catastrophe. Suppose original function returns a value 2, and after function redefinition, it returns 1. It would be really hard to debug this issue when your codebase is huge.
But but but… performing an A/B test is an exception to this rule. Because you will be pushing your A/B test’s code from a testing tool, for example, “oracle maxymiser”. After your experimentation is done, you will turn off your campaign.
Best Practices
- Always have a separate try/catch block for performing your original functionality and your new functionality. Because if something breaks in your new code, it makes sure that the original functionality is not hampered.
- Always have a return statement. If you are redefining a function. When you are calling the original functionality to save the return value into a variable. And return this value from your redefined function as well.
- Never change the return value. Until you are absolutely sure it would not break things. Because you never know the effect change in return value might cause.
Conclusion
This magical tool gives you powers to completely change your website’s UI on the fly without being dependent on production release. But always remember with great power, comes great responsibilities. Use this tool wisely, and always follow the best practices blindly.
Up Next
Has your codebase moved to Single Page Applications? Like, React and you still want to perform A/B tests on the fly? Stay tuned in my upcoming blog posts I will be demonstrating how you can use function redefinition to intercept react’s internal life cycle to perform A/B tests.