Why I do not use setVar

In his posting on AEP Web SDK Debugging, which is excellent, my colleague Julien Piccini wrote about Data Elements, Promises, and how you can use _satellite.setVar() to store return values.

As always when I see someone use setVar, my first reaction is “I should really finish this post about why I don’t use setVar at all”, only this time, I’m doing it, for real!

Here is a short explanation of what setVar is, and two reasons why I do not use it.

getVar and setVar

In Launch (and DTM), _satellite.getVar() is a method that allows you to query a Data Element.

A Data Element is how you access data in Launch. It encapsulates the complexities of how to actually get that data, and in that sense, a Data Element is a recipe.

A lot of the Data Element Types that are provided by the Core and other Extensions are very simple, which means they are good at hiding away how they really do it, but think of a Custom Code Type Data Element, and there you go: it is a recipe. The others are really just being nice to you.

For me, _satellite.getVar() is totally equivalent to “let’s do what the recipe say, and then use the result”.

I think I started thinking like this since the day I read the phrase “a Data Element will try to reset its value each time it’s referenced” in Jim Gordon’s excellent Adobe Launch: Data Elements Guide.

Now, _satellite.setVar() can be used to write a value into something called a “CustomVar”. This has been ported straight over from DTM.

If you use _satellite.setVar('name', 'Nadezhda Francine Cherneshevsky');, you can use _satellite.getVar('name'); somewhere else on the same page, to get Nadia’s full name.

Caveat: this only works if there is no Data Element called ‘name’ in your Launch setup.

So setVar can be used to write CustomVars, and getVar is able to retrieve them.

Confusing

And that is the very first reason for me not to use setVar.

While getVar is able to return Data Element values and CustomVars, I feel that there is no symmetry here.

In my world, getVar is for DEs, and setVar is not.

Heck, if you check the sources, setVar is actually called SetCustomVar!

But above my own feelings, which, let’s be honest, are largely irrelevant in the bigger picture, this mix-up creates some actual confusion, and some barriers to understanding, I find.

People often think of Data Elements as variables. There is a setter and a getter, so hey! Variables!

They do think of CustomVars, but that is not spelt out anywhere in the documentation, really, and a lot of people who approach from this path have trouble getting Data Elements and what they are.

If there was a getDataElement, and if getVar and setVar were solely for CustomVars, I think we’d have less confusion.

Ah, the joys of legacy!

Not safe enough (for me)

Let’s say you heed my advice, and you really treat DEs one way, and CustomVars differently. You have documented both. I still don’t like it.

Example: You have a CustomVar named ‘xLanguage’ that you use for storing the language that someone selected, as opposed to the browser or page language. You use setVar to set it, and getVar to use it somewhere else on the page.

This is all fine, until the day that someone creates a Data Element called ‘xLanguage’ and all of a sudden, your logic is kaput.

Because of the multi-functional nature of _satellite.getVar(), the developers had to make a choice: do we check Data Elements first? Or CustomVars?

The answer, Luke, is in the sources, specifically in lines 78 – 108 of the createGetVar.js file: Data Elements are read before CustomVars with the same name.

Or: you can only use a CustomVar safely if there is no Data Element with the same name.

And the system does not guarantee that, or flag it up at all.

Notes

Those two reasons, for me, are enough. I won’t use setVar, and I won’t tell anyone to do it.

But, Jan, I hear you ask, how do we store values, then?

There are different meanings in the word “store”, and CustomVars only cover the pretty narrow angle of “store data for later use on the current page”.

For that, I would simply use the _satellite object itself.

So, to take the example from above, if I wanted to store the language that a visitor has selected in a form, I would do this:

// selected language is available in a variable called 'selectedLang'
_satellite._ags055 = _satellite._ags055 || {};
_satellite._ags055.formSelectedLanguage = selectedLang;

I’m using “_ags055” as a sort of anchor here, for different data points. It is the short code of my account. Most Adobe Consultants have one of those. In your case, you could use your clientcode, or maybe your AdobeOrg ID. If you want to be extra-paranoid, add a prefix, and you should end up with something that will never clash.

The cool thing: I can create a good old, standard Data Element, to read that value! So I can very easily use it somewhere else on the page.

For all other meanings of “store”, CustomVars would not do the job, and most people would use cookies, SessionStorage, or LocalStorage.