feat(styles): add tokens get function

[oliverschuerch]

No description provided.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0dde7df

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[swisspost-bot]

Related Previews

• https://preview-3502--swisspost-web-frontend.netlify.app
• https://preview-3502--swisspost-design-system-next.netlify.app

[alizedebray]

I get this error when using "with" in two files that end up in the same index file:

But maybe we could have only one map for all component tokens, what do you think?

[gfellerph]

But maybe we could have only one map for all component tokens, what do you think?

Dang, I had so much fun. If we use one map, we loose the discoverability of all the tokens that belong to one component. What we could do instead is using a convention for the map name, so you'd only had to provide the name of the component without post- prefix, e.g. tokens.get('h1', 'font-family') and the function would do map.get(post-h1, post-h1-font-family). Would that work with our current naming conventions for component tokens?

[oliverschuerch]

But maybe we could have only one map for all component tokens, what do you think?

Dang, I had so much fun. If we use one map, we loose the discoverability of all the tokens that belong to one component. What we could do instead is using a convention for the map name, so you'd only had to provide the name of the component without post- prefix, e.g. tokens.get('h1', 'font-family') and the function would do map.get(post-h1, post-h1-font-family). Would that work with our current naming conventions for component tokens?

This will as well not work without any problem, because we have 3 different files where the map could come from (elements, components, utilities).
Threrefore the map need to be namespaced, e.g. map.get(ns.$post-headings, 'key')

[oliverschuerch]

I get this error when using "with" in two files that end up in the same index file:

But maybe we could have only one map for all component tokens, what do you think?

What happens, when you only build the styles package? Do you have the same problem there?
I'm asking, because if it's just a configuration problem (in vite), we could maybe fix it there.

[alizedebray]

What happens, when you only build the styles package? Do you have the same problem there?

I get the same issue:

[alizedebray]

What we could do instead is using a convention for the map name

@gfellerph as far as I know, Sass doesn’t allow retrieving variables using a dynamic name like token-maps.$post-#{$component-name}. However, to improve discoverability, we could organize our tokens with nested maps. This way, all tokens for a component are grouped within a single map inside a root token map, like so:

$tokens: (
  'h1': (
    'post-h1-font-family': var(--post-sem-font-family-default),
  ),
);

map.get($tokens, h1, post-h1-font-family)

This will as well not work without any problem, because we have 3 different files where the map could come from (elements, components, utilities).

@oliverschuerch is it necessary to have 3 separate files? If so, we could also create 3 files for the token functions: element-tokens.get, component-tokens.get, and utility-tokens.get, which could all be simplified to tokens.get when imported using the as keyword. What do you think?

[oliverschuerch]

@alizedebray and @gfellerph
I found another solution, how to set the used map.

 // here you could also load elements and/or utilities
@use '../tokens/components' as components;
@use '../functions/tokens' as tokens;
 
// set the default map to use or always use the third function parameter to specify a different map.
tokens.$default-map: components.$post-body;
 
/*
lets say you have the following keys in the map:
- 'post-html-something'
- 'post-body-font-family'
- 'post-body-font-size'
- 'post-body-margin'

then use it like so:
tokens.get($prefix, $key-name, $map)
while $prefix can be used with or without "post-"
*/
html {
  something: tokens.get('html', 'something');
}

body {
  font-family: tokens.get('post-body', 'font-family');
  font-family: tokens.get('body', 'font-family');
  font-family: tokens.get('body-font', 'family');
  font-size: tokens.get('body-font', 'size');
  
  font-family: tokens.get('body', 'font-family', $my-custom-map);  // use a different map than the default one
}

I've pushed this solution. Try it out if you like ;)

[oliverschuerch]

What we could do instead is using a convention for the map name

@gfellerph as far as I know, Sass doesn’t allow retrieving variables using a dynamic name like token-maps.$post-#{$component-name}. However, to improve discoverability, we could organize our tokens with nested maps. This way, all tokens for a component are grouped within a single map inside a root token map, like so:

$tokens: (
  'h1': (
    'post-h1-font-family': var(--post-sem-font-family-default),
  ),
);

map.get($tokens, h1, post-h1-font-family)

This will as well not work without any problem, because we have 3 different files where the map could come from (elements, components, utilities).

@oliverschuerch is it necessary to have 3 separate files? If so, we could also create 3 files for the token functions: element-tokens.get, component-tokens.get, and utility-tokens.get, which could all be simplified to tokens.get when imported using the as keyword. What do you think?

This would be a possible solution, but as soon as we add another file (like 'elements', 'components' or 'utilities') we would need to add more functions.

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@angular/[email protected]	None	+1	21.2 MB	angular, google-wombot
npm/@ng-bootstrap/[email protected]	Transitive: environment, filesystem, unsafe	+90	27.9 MB	maxokorokov
npm/[email protected]	environment, filesystem	0	79.1 kB	motdotla
npm/[email protected]	network	+3	493 kB	node-fetch-bot
npm/[email protected]	environment, filesystem Transitive: shell	+13	834 kB	bret
npm/[email protected]	environment, filesystem, unsafe	0	7.7 MB	prettier-bot
npm/[email protected]	None	0	84.9 kB	typescript-bot
npm/[email protected]	None	0	21.9 MB	typescript-bot

🚮 Removed packages: npm/@angular/[email protected]), npm/@stencil-community/[email protected]), npm/@stencil/[email protected]), npm/@stencil/[email protected]), npm/@stencil/[email protected]), npm/@stencil/[email protected]), npm/@stencil/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@storybook/[email protected]), npm/@swimlane/[email protected]), npm/@tokens-studio/[email protected]), npm/@tsconfig/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@types/[email protected]), npm/@typescript-eslint/[email protected]), npm/@typescript-eslint/[email protected]), npm/@web-types/[email protected]), npm/[email protected]), npm/[email protected]), npm/[email protected]), npm/[email protected]), npm/[email protected]), npm/[email protected]), npm/[email protected]), npm/[email protected])

View full report↗︎

[alizedebray]

This would be a possible solution, but as soon as we add another file (like 'elements', 'components' or 'utilities') we would need to add more functions.

Sure, though this will probably not happen happen too often.
The upside is that it will save us from having to write the map for every file.

[oliverschuerch]

Depends on #3506

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud