You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title:
Performance considerations for nested vs. flattened design token access in reactive property bindings
Body:
Hello,
I’m implementing Material Design token support in Slint and have encountered a design trade-off between developer experience (boilerplate reduction) and runtime reactivity performance.
Context
A single component property (e.g., font family, weight, size) may map to multiple design tokens based on conditional logic (e.g., role, emphasized).
If design tokens are grouped using structs, retrieving and applying values becomes concise:
inproperty <TypeRole> role;
inproperty <bool> emphasized;
private <TypeRoleStyle> style: {
emphasized
? role == TypeRole.DisplaySmall
? Typescale.emphasized_display_small
: role == TypeRole.DisplayMedium
? Typescale.emphasized_display_medium
: role == TypeRole.DisplayLarge
? Typescale.emphasized_display_large
: role == TypeRole.HeadlineSmall
? Typescale.emphasized_headline_small
: role == TypeRole.HeadlineMedium
? Typescale.emphasized_headline_medium
: role == TypeRole.HeadlineLarge
? Typescale.emphasized_headline_large
: role == TypeRole.TitleSmall
? Typescale.emphasized_title_small
: role == TypeRole.TitleMedium
? Typescale.emphasized_title_medium
: role == TypeRole.TitleLarge
? Typescale.emphasized_title_large
: role == TypeRole.BodySmall
? Typescale.emphasized_body_small
: role == TypeRole.BodyMedium
? Typescale.emphasized_body_medium
: role == TypeRole.LabelSmall
? Typescale.emphasized_label_small
: role == TypeRole.LabelMedium
? Typescale.emphasized_label_medium
: role == TypeRole.LabelLarge
? Typescale.emphasized_label_large
: Typescale.emphasized_body_large
: role == TypeRole.DisplaySmall
? Typescale.display_small
: role == TypeRole.DisplayMedium
? Typescale.display_medium
: role == TypeRole.DisplayLarge
? Typescale.display_large
: role == TypeRole.HeadlineSmall
? Typescale.headline_small
: role == TypeRole.HeadlineMedium
? Typescale.headline_medium
: role == TypeRole.HeadlineLarge
? Typescale.headline_large
: role == TypeRole.TitleSmall
? Typescale.title_small
: role == TypeRole.TitleMedium
? Typescale.title_medium
: role == TypeRole.TitleLarge
? Typescale.title_large
: role == TypeRole.BodySmall
? Typescale.body_small
: role == TypeRole.BodyMedium
? Typescale.body_medium
: role == TypeRole.LabelSmall
? Typescale.label_small
: role == TypeRole.LabelMedium
? Typescale.label_medium
: role == TypeRole.LabelLarge
? Typescale.label_large
: Typescale.body_large
};
font-family: style.family;
font-weight: style.weight;
font-size: style.size;
letter-spacing: style.tracking;
Even less boilerplate is possible with deeper nesting:
This nesting reduces boilerplate significantly, especially given that a full design system can contain over 1000 tokens.
Problem
Most component tokens reference system tokens (named md.sys.* in Material Design). Since Slint’s reactivity is property‑level, a change to a single system token could cause struct re‑evaluation across all components' tokens.
Question
Will deep nesting of token structs cause meaningful performance issues in practice?
Which approach would you recommend for a large‑scale design system:
Nesting (better DX, possible re‑evaluation overhead), or
Flattening (more boilerplate, potentially less reactivity churn)?
Example of Current Complexity
Attached is an abbreviated version of my current Typescale implementation. Half of our component tokens follow this pattern.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Title:
Performance considerations for nested vs. flattened design token access in reactive property bindings
Body:
Hello,
I’m implementing Material Design token support in Slint and have encountered a design trade-off between developer experience (boilerplate reduction) and runtime reactivity performance.
Context
A single component property (e.g., font family, weight, size) may map to multiple design tokens based on conditional logic (e.g.,
role,emphasized).If design tokens are grouped using structs, retrieving and applying values becomes concise:
Even less boilerplate is possible with deeper nesting:
This nesting reduces boilerplate significantly, especially given that a full design system can contain over 1000 tokens.
Problem
Most component tokens reference system tokens (named
md.sys.*in Material Design). Since Slint’s reactivity is property‑level, a change to a single system token could cause struct re‑evaluation across all components' tokens.Question
Example of Current Complexity
Attached is an abbreviated version of my current
Typescaleimplementation. Half of our component tokens follow this pattern.Full
typescale.slintis attached for reference.In
MaterialText, you can see the repeated per‑property conditional chains. This is the kind of boilerplate nesting would eliminate.Thank you for your guidance.
typescale.slint.txt
Beta Was this translation helpful? Give feedback.
All reactions