Common Cross-Libraries Token Architecture: Add Semantic Tokens From Outside

[julien-deramond]

[!WARNING]
On hold until the common cross-libraries token architecture has been implemented and challenged with the creation of some components

Description

The possibility of adding semantic tokens from outside was envisaged in https://github.com/Orange-OpenSource/ouds-ios/issues/33, but it was not studied in depth at the time. The complexity of creating prototypes without an existing library made this task challenging. Strategically and efficiently, adding semantic tokens from outside was deemed out of scope.

Now that the common cross-library token architecture has been implemented and validated through the creation of various components, it's time to study and implement the second version of this architecture. This new version will allow the addition (and possibly removal) of semantic tokens from outside when creating a new theme.

Study

• [ ] Study the limitations and the way it could be done on Android

Technical details

TODO

[pylapp]

Just for information, it seems to be possible to define today with the current architecture implemented in #33 some semantics tokens.

Indeed, there are semantic tokens shared for all themes (i.e. all semantic tokenswe have today for dimensions, spacings, sizings, etc), i.e. in highest level. These semantic tokens rely on primitive types (Int, Double, String).

A theme can define its own semantic tokens using the same primitive types or typealiases exactly like it is possible to do for raw tokens. However of course these semantic tokens can only be used in the module of the theme which defined them. These "theme exclusive" semantic tokens can be used in the module for components tokens or also to override existing semantic tokens if types match.

We should test it, but it seems it is still possible today.