USF-1877: Headers from config

[sirugh]

Note!

• ✅ Before we merge, we have to duplicate the structure of the dev config to the stage and prod configs!
• JIRA: https://jira.corp.adobe.com/browse/USF-1877

The Ask

The headers and query parameters used by the PDP dropin are stored in the content space in config files. These values are read per key:

setFetchGraphqlHeaders({
  'Content-Type': 'application/json',
  'x-api-key': await getConfigValue('commerce-x-api-key')
});

Therefore, new query params or headers must be added to the config AND to the codebase.

setFetchGraphqlHeaders({
  'Content-Type': 'application/json',
  'x-api-key': await getConfigValue('commerce-x-api-key'),
  'some-new-header': await getConfigValue('some-new-header-key') // <-- This isn't great!
});

We want these headers to be managed entirely in config rather than requiring developers to make code changes.

The Solution

We can add config values with some consistent path, ie commerce.headers.[scope].[header] where scope is like pdp and header is the string header key. The corresponding value will be injected as header or query param, programatically.

// if config has "commerce.headers.pdp.foo": "bar"
// then the following should assign { "foo": "bar" }
setFetchGraphqlHeaders(await getHeadersFor('pdp'));

The Downside

Assuming headers will be defined in this way, then there is potential for duplication in the config. For example if two dropins require the same value, there will be duplicate values, for example:

// both have same value in config
getConfigValue("commerce.headers.pdp.Magento-Environment-Id") 
getConfigValue("commerce.headers.checkout.Magento-Environment-Id")

Additionally, there are places where these values are used but not as headers. For example, here used to be getConfigValue('commerce-customer-group) but we removed that entry to reduce duplication in config. However this results in coupling of that line to the cs.Magento-Customer-Group header in config.

Test URLs:

• Before: https://main--aem-boilerplate-commerce--hlxsites.aem.live/products/crown-summit-backpack/24-MB03
• After: https://USF-1877--aem-boilerplate-commerce--hlxsites.aem.live/products/crown-summit-backpack/24-MB03

Validate this on any of the following:

• http://localhost:3000/products/crown-summit-backpack/24-MB03
• https://usf-1877--aem-boilerplate-commerce--hlxsites.aem.page/products/crown-summit-backpack/24-MB03
• https://main--aem-boilerplate-commerce--hlxsites.aem.page/products/crown-summit-backpack/24-MB03

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run PSI checks
• Re-sync branch

Commits

• 6cf03bd 🔄 (latest)
• ba650fe ✅
• 4b62eda ✅
• 85d850f ✅
• 9e30278 ✅
• ea7c6dd ✅
• 8b39b5f ✅
• 95e8869 ✅
• 2feac6d ✅
• b512edf ✅
• feea93a ✅
• eff0b42 ✅
• 963fe52 ✅
• 3d37b35 ✅
• 4fa7c7e ✅
• bde37e8 ✅

[aem-code-sync]

	Page	Scores	Audits	Google
📱	/products/crown-summit-backpack/24-MB03
🖥️	/products/crown-summit-backpack/24-MB03
📱	/products/crown-summit-backpack/24-MB03
🖥️	/products/crown-summit-backpack/24-MB03

[sirugh]

If we dedupe the config, so that we only have values in one place when possible, then we will end up with quite a lot of these sort of calls, where the key doesn't really make sense in the context of what we're passing the value to.

So it's a choice, I guess. Either we keep multiple duplicated values within the config, so the keys are more explicit, or we remove extra values and rely on just a single config value.

[sirugh]

Ideally the PLP and LS widget are updated to allow for passing of headers in a single headers object rather than as top-level props on this "config" object. Then we could use the same iteration logic as the PDP dropin in this PR.

[sirugh]

major change - we are reverting back to rely on headers for request data differentation. the only query param we add is now done for cache busting purposes.