Proposal to include gppString and applicableSections in listenerRegistered event object

[nealrosen]

Problem

In many cases, vendor scripts need access to the raw gppString and applicableSections in order to forward them to downstream components. In these cases, there is no need to parse the values for local decisioning. To get these 2 signals, 2 commands may be required.

• Call addEventListener
• If status is "loading", wait for next event
• else call getGPPData command to get the gppString and applicableSections signals

Having this conditional logic that calls either 1 or 2 commands seems to add unnecessary complexity to vendor scripts.

Proposed solution

The initial response from the addEventListener command is the "listenerRegistered" event. The data property in the EventListener object for this event is a boolean signifying whether the listener was registered successfully or not. The proposal is to continue to return false (or perhaps null) if the listener fails to be registered. But on successful registration, return an object in the data property. This data object would include (if available) the gppString and applicableSections.

With these signals included in this initial listenerRegistered event, the vendor script logic would be simplified to something like this...

• Call addEventListener
  • if status is "loading", wait for next event
  • else read the gpp signals from the EventListener data object and forward as needed to downstream components

[janwinkler]

Addition: Please note that there is a discussion in TCF EU to remove the getTCData command and instead force the use of event Listener (similar to issues #51 and #52). Since getGPPData was ONLY included in order to be similar to the TCF, we should go the same route and remove it from GPP (in favor of adding the content to the event listener as described by Neal above).