And hooks…

import { createContext, ReactNode, useContext, useEffect, useMemo } from ‘react’;

type Theme = ‘legacy’ | ‘osmo’;

export type ThemeContext = { theme: Theme; };

export const ThemeContext = createContext<ThemeContext>(null as unknown as ThemeContext);

export function ThemeProvider({ isInterEnabled, theme, children, }: { isInterEnabled: boolean; theme: Theme; children: ReactNode; }) {

useEffect(() => { document.documentElement.setAttribute(‘data-theme’, theme); }, [theme]);

useEffect(() => { if (isInterEnabled) { document.documentElement.setAttribute(‘data-inter’, ‘true’); } else { document.documentElement.removeAttribute(‘data-inter’); } }, [isInterEnabled]);

const contextValue = useMemo( () => ({ theme, }), [theme], );

return <ThemeContext.Provider value={contextValue}>{children}</ThemeContext.Provider>; }

export function useTheme() { return useContext(ThemeContext); }

Design tokens

Before the North Star was revealed, our team was already refactoring our token architecture.

Our legacy token system was a blend of base and semantic, so it wasn’t scalable. Or themable. Hence the refactor.

Once this rebrand was announced, we had to adjust our tokens work without losing any of our progress.

Since we were using data attributes controlled by a flag, we could target the data attributes in our CSS to control our token values.

Considering the 10-week time frame, we chose to focus on using the data attribute to map our semantic tokens to base tokens in either the legacy or osmo theme. Our squads have been leaning on using our design tokens, so this would allow our re-theme to happen seamlessly.

We used a 1:1 mapping of our values and tested our rebrand by toggling on our flag.

This was especially helpful because our legacy tokens were blending base and semantics in their naming structure, and we could introduce a new set of semantic tokens quickly without much fuss.

The tokens that we were most concerned about where our application level tokens. now, we could have a separate set of base tokens for our our colors and fonts and our sizes in our legacy theme and our osmo theme.

By leveraging data attributes through feature flagging, we could test out our new token values in the app at runtime, without impacting any of the other teams’ work.

Even better, we could use this data attribute to wrap blocks of CSS code, and when it’s time to remove legacy styles, we can do it quickly.

We could create a set of semantic tokens…

:root { —color-error-base: var(—danger-red-base); —color-info-base: var(—info-blue-base); —color-warning-base: var(—alert-orange-base); —color-success-base: var(—primary-green-base);

--focus-color: var(--info-blue-safe);
--primary-color: var(--primary-green-safe);
--text-color: var(--gray-black);
--text-color-danger: var(--danger-red-dark);

}

We could add the top nav into the rebranded UI by turning on the topbar-spike flag.

import classNames from ‘classnames’; import { useTheme } from ‘theme’; import Topbar from ‘components/Topbar/Topbar’; import ‘stylesheets/components/App’;

export const App = ({ className, children, isTopbarSpikeEnabled, }: AppProps) => { const classes = classNames(‘App’, className, { ‘App—with-top-bar’: isTopbarSpikeEnabled, }); const { theme } = useTheme();

return ( <div className={classes}> <SkipToContent /> {isTopbarSpikeEnabled && <Topbar />} <AppNavContainer theme={theme} isTopbarSpikeEnabled={isTopbarSpikeEnabled} /> <main className={classNames(‘App-main’, { ‘App-main-with-topbar’: isTopbarSpikeEnabled })} id=”content” > {children} </main> </div> ); };

export default App;