Skip to content
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

Merged
merged 11 commits into from
Feb 3, 2025
Merged

Refactor commercial boot process #1764

merged 11 commits into from
Feb 3, 2025

Conversation

emma-imber
Copy link
Contributor

@emma-imber emma-imber commented Jan 24, 2025

What does this change?

Splits out the loadModules, recordCommercialMetrics and bootCommercial functions into a separate commercial-boot-utils file for tidiness. Also splits consented.ts into two files - ad-free.ts and consented-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 the robust 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!

Copy link

changeset-bot bot commented Jan 24, 2025

🦋 Changeset detected

Latest commit: d88d3ee

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
@guardian/commercial Minor

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

@emma-imber emma-imber changed the title Refactor module loading to make it easier to read Refactor commercial boot process Jan 24, 2025
Copy link
Contributor

github-actions bot commented Jan 24, 2025

Ad load time test results

For consented, top-above-nav took on average 4105ms to load.
For consentless, top-above-nav took on average 4169ms to load.

Test conditions:

  • 5mbps download speed
  • 1.5mbps upload speed
  • 150ms latency

@Jakeii
Copy link
Member

Jakeii commented Jan 28, 2025

Looks much nicer to me!

@Jakeii
Copy link
Member

Jakeii commented Jan 28, 2025

The whole array of module names with init functions and catchErrorsAndReport looks to be just to help with error reporting?

I can't ever recall looking for errors in sentry using these, could we get rid and simplify further?

Comment on lines +21 to +22
/* webpackChunkName: "consentless-advertising" */
'./init/consentless-advertising'
Copy link
Member

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?

Copy link
Contributor Author

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!


// all modules needed for commercial code and ads to run
const commercialModules: Modules = [
['cm-adFreeSlotRemoveFronts', adFreeSlotRemove],
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

@arelra arelra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice refactor ✨ !

@emma-imber
Copy link
Contributor Author

The whole array of module names with init functions and catchErrorsAndReport looks to be just to help with error reporting?

I can't ever recall looking for errors in sentry using these, could we get rid and simplify further?

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),
Copy link
Contributor

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

Copy link
Contributor Author

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!

}
};

export { bootCommercial };
Copy link
Contributor

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!

@@ -18,13 +18,18 @@ void (async () => {
!commercialFeatures.adFree
Copy link
Contributor

@i-hardy i-hardy Jan 29, 2025

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.

Suggested change
!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.

@emma-imber emma-imber marked this pull request as ready for review January 30, 2025 11:30
@emma-imber emma-imber requested a review from a team as a code owner January 30, 2025 11:30
Copy link
Contributor

@cemms1 cemms1 left a 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! 👏

@emma-imber emma-imber merged commit 84e8bfb into main Feb 3, 2025
14 checks passed
@emma-imber emma-imber deleted the ei/refactor-boot-logic branch February 3, 2025 14:26
@prout-bot
Copy link
Collaborator

Seen on PROD (merged by @emma-imber 1 minute and 42 seconds ago) Please check your changes!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants