This issue aims to define and implement a common cross-libraries token architecture for the tech libraries: Android, iOS, Flutter, and web.
Design tokens are defined on the design side via Figma, and Figma's capability to handle and define tokens is more limited compared to what we can do on the development side. So there will be a slight discrepancy between the design and the tech side.
In essence, Figma’s token mechanism requires designers to pre-create a set of tokens that may not be inherently useful for the core part of our tech libraries.
On the technical side, it is important to define what is available by default:
for developers using the Orange theme (default)
what can be overridden for country-specific themes, and how overrides will function for B-Brand themes
This must be considered at different levels of the token stack, including primitive raw values, semantic tokens, and component tokens.
Our objective is to establish a common cross-library architecture to ensure uniformity in terminology and implementation.
[!NOTE]
Closing this issue will unlock all the "Tokens: *" issues in this repository
[!IMPORTANT]
The possibility to add semantic tokens from outside is a topic we'd like to deep dive in. However, creating prototypes for that now, is considered as too complex as we don't have yet libraries handling tokens. The safest approach is to limit the scope of this study.
Said differently, our libraries will define only the raw/semantics/components tokens needed for the global core Orange theme. And only these tokens would be updatable. It also means that our tech libraries won't contain at first the concepts coming from B-Brands that are not used in the core library. Basically, it's like what has been done in ODS, but with a new constraint: the theme should be extendable.
An extended theme can rewire semantic tokens with its own raw tokens and component tokens with semantic tokens. It defines its own raw tokens (often generated from Figma) and doesn't need to access the raw tokens of the parent theme.
Description
This issue aims to define and implement a common cross-libraries token architecture for the tech libraries: Android, iOS, Flutter, and web.
Design tokens are defined on the design side via Figma, and Figma's capability to handle and define tokens is more limited compared to what we can do on the development side. So there will be a slight discrepancy between the design and the tech side.
In essence, Figma’s token mechanism requires designers to pre-create a set of tokens that may not be inherently useful for the core part of our tech libraries.
On the technical side, it is important to define what is available by default:
This must be considered at different levels of the token stack, including primitive raw values, semantic tokens, and component tokens.
Our objective is to establish a common cross-library architecture to ensure uniformity in terminology and implementation.
Based on the study done on the Android side in https://github.com/Orange-OpenSource/ouds-android/issues/34, in terms of customization, our libraries will need to handle first only a light customization such as white-label themes.
Said differently, our libraries will define only the raw/semantics/components tokens needed for the global core Orange theme. And only these tokens would be updatable. It also means that our tech libraries won't contain at first the concepts coming from B-Brands that are not used in the core library. Basically, it's like what has been done in ODS, but with a new constraint: the theme should be extendable. An extended theme can rewire semantic tokens with its own raw tokens and component tokens with semantic tokens. It defines its own raw tokens (often generated from Figma) and doesn't need to access the raw tokens of the parent theme.
It corresponds to the schema presented in the "Android architecture" section in https://github.com/Orange-OpenSource/ouds-android/issues/34.
Implementation
As a summary, for the implementation part:
Study
Technical details
TODO