Something like @guardian/dotcom-config

[sndrs]

Just had a thought trying out CMP stuff – how do people feel about a @guardian/dotcom-config-type package that could return window.guardian.config if available or hit and locally cache an endpoint on dotcom that returned things like switches, tests etc?

it would make working with remote config settings outside dotcom apps much easier...

[JamieB-gu]

@davidfurey would this be a step towards your thoughts about a generic/cross-platform API for retrieving config and supporter information? One that could read from the window.guardian object on dotcom and from sources like Bridget on apps?

[davidfurey]

Yes, this sounds like a good opportunity to provide that abstraction.

[gtrufitt]

Further to what Jamie was saying in CS Infra meeting, I had a similar thought.

I wonder if the API of this would be:

// On Frontend
const configGetter = getConfigFromTheWindow(configKey, default); // Maybe this is a default function that comes with the module?

// On Apps
const configGetter = goToTheNativeLayer(configKey, default);

// Somewhere else that doesn't fancy hosting their own config
const configGetter = (configKey, default) => fetch('//configAPI').then(r => r.json()).then(// return config key or default); 

Whatever getter is used in a platform can then initialise into the config.

// Then the module provides an initialiser
initConfig(configGetter);

The module could also provide a typed schema and it would need to be truly 'shared' stuff (Commercial, RR, Switches). Also user-specific stuff that has to be on the window.

Really, it would be great to tidy this up in DCR because it's a bit of a mess (we have window config and then hydrated app config - having both is super confusing but it is currently required because commercial goes to the window directly) and even just better defining a shared schema (beyond the half-baked one we have at the moment) would be useful..

Sidenote: Maybe that endpoint means that applications can hit the config with an agent and put the key-value pairs on the window. So a mechanism for creating a config (probably using AWS KVS).

[sndrs]

how would configGetter be provided to @guardian/config package?

if it needs to live on window, is it different to window.guardian.config?

i'm imagining something like

// @guardian/config
export const getConfig = async () => {
	window.guardian = window.guardian || {};
	window.guardian.config =
		window.guardian.config || (await fetch('https://theguardian.com/config'));
	return window.guardian.config;
};
export const getSwitches = async () => {
	const { switches } = await getConfig();
	return switches;
};

import { getSwitches } from '@guardian/config';

if a platform populates window.guardian.config already then that network call can be skipped

[JamieB-gu]

@gtrufitt's suggestion looks interesting. You're essentially talking about dependency-injecting the platform-specific effects? Sounds similar to what libraries like ZIO do.

It might help to define what sort of questions we'd like this API to answer? For example, what functions would the commercial stack like to call? What functions would we use to find out about a user's RR status?

[sndrs]

think i'm going to make a start on this ASAP. not sure in what direction given the above, but any thoughts on what should we call it?

@guardian/config feels too generic to me, @guardian/dotcom-config too precise (doesn't include apps).

any of these?

• @guardian/ui-config
• @guardian/page-config

[gtrufitt]

Is it client side only w're talking yeah? client-config?

[sndrs]

yeah i think so - is there value/need server side too?

[gtrufitt]

I guess if you're using modules ⚡ ISOMORPHICALLY ⚡

[sndrs]

🤔 does that happen outside DCR at the moment? would you want to use it DCR in place of the config from frontend?

[gtrufitt]

Probably not no, as that would be another request at server time. Passing then through window but using this utility to access that would be better. So I think client-side makes sense for the focus of this

[sndrs]

do you think the endpoint should live in frontend or DCR?

[sndrs]

draft here guardian/libs#48

[sndrs]

guardian/libs#48 is merged now, so you can do

import { getSwitches } from '@guardian/libs';

getSwitches().then((switches) => {
    if (switches.mySwitch) {
        // do the thing i want
    }
});