unicorn literally means one horn how dare you mock this institution with your duocorn rhinoceros

hence the comment about tracking ;) anything more than recording your events as they happen are a security and privacy risk

great example of a code smell, too! JS needs to know about styles?

shouldn’t be styling in JS! make it asd/remove a class instead

need to know whether to load content or not? save it to local/session storage! don’t make a server call if it already exists!

need to enhance your tracking? include it with your payloads as it happens, you’re asking for race conditions

client side disabled local caching? great! working as intended. make a graceful fall-back

everything here is a short term problem that belies long term tech debt. tight coupling sounds sexy, but SOLID principals and The Law of Demeter exist to stop our codebases from rotting if we can’t change it, then it’s not software it’s hardware

I blame Eastern Thom Yorke

HELL YEAH! nice work 👏🏼

Also worth noting media queries for specific use cases, like dark mode or high contrast: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-color-scheme

Sorry, just saw your reply. Great question! That’s the beauty of a variable. If they’re all supposed to use the same values, then it’s one place to control them, one place to update them. Single Responsibility Principal! 😎

That means you won’t run into the bug of updating it in one place, but forgetting /not knowing to update it in another.

It’s also where tokens (ie: 2-layered variables) shine. All links should use the accent colour. Single variable for that high level concept, but each theme can specify what the low level concept should be (eg: theme 1 uses your design system’s green-bright)

And if that concept’s concretion (ie: actual / raw value) needs to change (eg: the green is now a different shade), it’s still only one place that needs to change

It also helps identify what areas use the same concept (eg: how many use the accent colour) and opportunities to combine/ deduplicate

Yep! This pattern will work on any website. You only need to be able to write CSS, and apply a class to the body tag.

AFAIK Jekyll uses Liquid for template flow control - you could set the class; or even load specific CSS that way too

Tokenise your styles with variable layers. Eg: put a class on your body tag for each theme, eg: dark-mode, high-contrast

Then define your components by abstract style variables, eg: button-color, heading-weight,

Then define the style variables for each theme:

body { –button-color: green; }

body.dark-mode { –button-color: blue; }

button { backgroud: var(–button-color); }

Then all you need to do is a simple JS function to set the appropriate theme class on your document body!

This way your components are compliant to your style guide, without needing to know the implementation details of your themeing Very SRP, much Demeter, such OCP

Apologies for psudocode, LMK if you have any furthers :)