Refactor macros.js by breaking logic groups into separate functions
Adds two new macro features:
disableDefaultMacros - Allows integrators to use adMacroReplacement() for only customMacros, skipping replacement of the default macros (ex. {player.id})
macroNameOverrides - Allows integrators to customize the names of any default macros, including dynamic macros. For example, they can replace {player.id} with {{{PLAYER_ID}}}, {tcf.gdprApplies} with {{GDPR}}, etc
Update docs and tests
The new options are passed as properties of the existing customMacros object:
One possible objection to this approach is that it introduces "magic properties" to customMacros that behave differently than other properties. They are implemented in such a way that there should not be any adverse side-effects (they are deleted from the customMacros object before it is processed), and I'm personally fond of the simplicity of this approach. It doesn't add any new parameters to adMacroReplacement() or the need for additional method calls.
Ideally, we would do something like this, but unfortunately it isn't backward-compatible:
This lets us adopt the ideal data structure in a backward-compatible way, but it adds a bit more conceptual complexity. It's also still very much a workaround.
2. Add 2 new methods that can be called before adMacroReplacement():
Description
This PR makes the following changes:
macros.js
by breaking logic groups into separate functionsadMacroReplacement()
for only customMacros, skipping replacement of the default macros (ex.{player.id}
){player.id}
with{{{PLAYER_ID}}}
,{tcf.gdprApplies}
with{{GDPR}}
, etcThe new options are passed as properties of the existing
customMacros
object:Notes
One possible objection to this approach is that it introduces "magic properties" to
customMacros
that behave differently than other properties. They are implemented in such a way that there should not be any adverse side-effects (they are deleted from thecustomMacros
object before it is processed), and I'm personally fond of the simplicity of this approach. It doesn't add any new parameters toadMacroReplacement()
or the need for additional method calls.Ideally, we would do something like this, but unfortunately it isn't backward-compatible:
If there are very strong objections to my approach, here are two other possible approaches:
1. Allow the
customMacros
argument to be a function that returns an object:This lets us adopt the ideal data structure in a backward-compatible way, but it adds a bit more conceptual complexity. It's also still very much a workaround.
2. Add 2 new methods that can be called before
adMacroReplacement()
:This is fairly clean, but it does require two separate method calls.