-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor commercial boot process #1764
Conversation
🦋 Changeset detectedLatest commit: d88d3ee The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Ad load time test resultsFor Test conditions:
|
Looks much nicer to me! |
The whole array of module names with init functions and I can't ever recall looking for errors in sentry using these, could we get rid and simplify further? |
/* webpackChunkName: "consentless-advertising" */ | ||
'./init/consentless-advertising' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is very minor so feel free to ignore :) What do we gain anything by adding -advertising
to all the chunks? Is it to help searching in dev tools?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was only to make the distinction between code that loads an ad and the ad free code really explicit to anyone looking at it for the first time. I'm not set on it at all - happy to go with the majority opinion!
src/init/consented-advertising.ts
Outdated
|
||
// all modules needed for commercial code and ads to run | ||
const commercialModules: Modules = [ | ||
['cm-adFreeSlotRemoveFronts', adFreeSlotRemove], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While we're here... do we ned the cm-
prefix to all the modules any longer. I suspect its something we carried over from Frontend. Could be a follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good point - I think this ties in with Jake's point about reporting. If we're only using the module names for error reporting, maybe we can remove them altogether
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice refactor ✨ !
Yeah I don't think I've ever used this either! It's also the only bit of code using catchErrorsAndReport, so we could delete the robust file if we got rid |
initDfpListeners, | ||
// Permutive init code must run before google tag enableServices() | ||
// The permutive lib however is loaded async with the third party tags | ||
() => initPermutive().then(prepareGoogletag), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this could be part of a separate bit of work to tidy up the Permutive/Googletag code, but it would be nice if this could be a module unto itself like the others rather than a random hard-coded function and comment breaking up the array
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to address this in a separate PR, but yes, agreed!
src/lib/init-utils.ts
Outdated
} | ||
}; | ||
|
||
export { bootCommercial }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit allergic to everything being called 'init' in any case, but given the export maybe this file could be named something like 'commercial-boot-utils'? I think it would be a little clearer. Breaking these out from the main file is a huge improvement though!
src/commercial.ts
Outdated
@@ -18,13 +18,18 @@ void (async () => { | |||
!commercialFeatures.adFree |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this condition be moved out into a named function that describes this particular state?
Eg.
!commercialFeatures.adFree | |
function shouldRunConsentless(consentState): boolean { | |
return window.guardian.config.switches.optOutAdvertising && | |
consentState.tcfv2 && | |
!getConsentFor('googletag', consentState) && | |
!commercialFeatures.adFree; | |
} | |
... | |
if (shouldRunConsentless(consentState)) { |
It would improve readability and make it clearer what all these conditions actually add up towards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels much easier to grok! 👏
Seen on PROD (merged by @emma-imber 1 minute and 42 seconds ago) Please check your changes! |
What does this change?
Splits out the
loadModules
,recordCommercialMetrics
andbootCommercial
functions into a separatecommercial-boot-utils
file for tidiness. Also splitsconsented.ts
into two files -ad-free.ts
andconsented-advertising.ts
. This (in my opinion) makes the ad free logic easier to find and clearer to read. By doing this, we also get rid of the idea of "base" and "extra" modules, which were confusingly named.Also removes the naming of the modules and no longer loads using the
catchErrorsAndReport
function. This also means we can delete therobust
module as this was the only use of it.Why?
Having explained this code several times over the last few weeks to different people, I have noticed a few parts that don't make immediate sense when you try to explain them (eg the naming of base vs extra modules). I think this little refactor is much more readable, and focuses the different bundle entry point files on the modules that they load.
Also, by having an ad-free specific file, we should be shipping less code to end users who don't see ads. I am also in favour of having the ad free check in the commercial file instead of the consented file, as I think it makes the purpose of each file much clearer to understand.
Would like to hear other people's thoughts on if this is an improvement or not!