Data elements in SPA when next page JSON is undefined

[aaronc10]

We are running into issues where a JSON is undefined in a subsequent page by design.

Suppose a data layer in an SPA:

Page 1: digitalData.abc returns "label X"

Page 2: digitalData.abc returns undefined

The data element (DE) that maps to it would:

Page 1: DE returns "label X" !

Page 2: DE returns "label X"

What's the best way, if it's possible, to make the DE return undefined in page 2?

I tried converting the DE to custom code (below). Doesn't work.

if(digitalData.abc == undefined){
  return undefined;
}
else {
  return digitalData.abc;
}

Any advice?

[jantzen_b]

Since you are using a SPA framework, the duration of the data element likely isn't getting reset even when you've set it to "page view".

You'll likely need to either reset the value of the data element after firing the beacon, or you'll need to apply the logic to conditionally set the data element before each beacon.

It looks like you've attempted the later in the code you've provided. Can you tell me what about that code doesn't work? For example, does the first value set always persist to the second beacon?

Alternatively, could you provide a URL where we could test?

Cheers,
Jantzen

[aaronc10]

Thanks for replying Jantzen. Unfortunately our test servers are in an internal environment.

I am not sure why the code doesn't work. To test it, I called _satellite.setVar('DE abc') first in a page where digitalData.abc has a value. I then navigated to a page where digitalData.abc is not populated and called _satellite.setVar('DE abc'). The return result was still the value of digitalData.abc. I then navigated to another page where digitalData.abc has a different value (say value B), called _satellite.setVar('DE abc'), then called _satellite.getVar('DE abc') and received Value B.

'DE abc' is configured via the code above.

What is the recommended practice when it comes to data elements in SPA? Am thinking of explicitly clearing all DEs in our page load rule, but that introduces a point of failure because all future DEs will have to be explicitly cleared. Another concern is the potential extra CPU time as opposed to just assigning variables directly to the data layer via code. That's unfortunate because we really want to use Launch's set variables UI to keep things clean and non-coder friendly.

[jantzen_b]

After speaking with one of our engineers about this, I found out the following:

Launch is designed to always retrieve a data element's value from its source every time the data element is used. If the value it retrieves is null or undefined, only then will it fall back to the "stored" value.

I believe this explains the behavior your seeing. I'm still working to see if there is a way to disable the fall back behavior or another work around that might help you accomplish what you are seeking.

[aseelund]

just fix up your JavaScript a bit

if(typeof digitalData.abc ===  'undefined' ){  // note:undefined is now a string value for the conditional

  return undefined; 

} 

else { 

  return digitalData.abc; 

} 

[aaronc10]

aseelund​, tried but still doesn't work.

[jantzen_b]

After speaking with our team, there is not a way to disable the fall back to the stored value. We've created a feature request for this change but I don't have an ETA on when it might be available.

I'm sure what you're asking could be accomplished via some custom javascript, but there isn't anything built into the UI to accomplish you're looking for as of today.

[aaronc10]

Thanks Jantzen. Not a big deal since we can just assign digitalData directly to props/evars. Thanks again.

[jantzen_b · Accepted solution]

aaronc10​

I've been told this change is actually going into production tomorrow!

[aaronc10]

That's awesome, thanks!